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INTRODUCTION 


Much  recent  work  has  focused  on  the  Investigation  of  Program  Manipulation  Systems 
[1.  S,  6,  7,  8,  12,  14,  16]  as  an  alternative  programming  paradigm  In  which  the 
PROCESSES  of  design  and  implementation  are  themselves  the  subject  of  study.  They 
are  captured  and  recorded  to  provide  documentation  of  the  program,  the  basis  for  Its 
validation,  and  the  framework  within  which  future  maintenance  will  occur. 

This  extension  of  the  conventional  programming  paradigm  to  Include  the  development 
of  the  program  as  a  computer  processable  object  (In  addition  to  the  program)  itself  Is 
quite  profound.  It  Is  comparable  to  the  early  recognition  that  programs  could  themselves 
be  treated  as  data,  enabling  computer  languages  to  be  developed.  Correspondingly,  by 
capturing  and  recording  the  development  processes,  a  set  of  tools  can  be  developed  to 
use  these  processes  as  data. 

Although  such  tools  do  not  yet  exist,  It  Is  easy  to  foresee  some  of  their  capabilities: 
automatically  generated,  up-to-date,  and  accurate  documentation  of  the  program  relating 
the  Implementation  back  to  its  specification;  explication  of  all  the  assumptions  used 
within  the  development  and  identification  of  the  decisions  made  therein;  validation  of  an 
Implementation  based  not  on  an  analysis  of  the  re'^ulting  program,  but  rather  upon  the 
process  by  which  It  was  produced;  maintenance  performed  by  modifying  the  development 
process  rather  than  by  attempting  to  modify  the  optimized  program;  and  automatic 
Instrumentation  to  test  the  performance  assumptions  Implicit  In  critical  design  and 
Implementation  decisions. 

Before  such  possibilities  can  be  realized,  however,  the  development  process  that 
currently  exists  only  within  people's  heads  must  be  made  explicit  and  recorded.  How 
can  this  be  accomplished? 

A  key  Insight  of  the  Program  Manipulation  approach  Is  that  transformations  provide  a 
sufficient  basis  for  the  development  process.  Each  development  decision  can  be 
represented  as  a  transformation  applied  to  the  program.  Thus,  a  development  Is  merely  a 
linear  sequence  of  transformations  applied  to  the  program.  (Unfortunately,  such  linear 
sequences  are  unintelligible,  and  like  programs,  must  be  structured  to  be 
undorstandable.)  But  what  programs  are  the  transformations  applied  to?  Since  the 
object  of  the  development  Is  to  produce  a  program,  the  resulting  program  Is  obviously  not 
the  one  to  which  transformations  are  applied. 

instead,  transformations  are  applied  to  the  PROGRAM  resulting  from  the  previous  stage 
of  development.  Each  stage  of  the  development  corresponds  to  the  transformation  of  a 
program  treated  as  a  specification  Into  another  treated  as  Implementation.  Thus, 
development  is  an  Iterative  (and  as  we  will  see  later,  sometimes  a  recursive)  process  of 
successive  refinement  In  which  a  specification  is  gradually  transformed  Into  an 
Implementation. 

This  implies  that  the  original  specification  of  the  program  Is  Itself  a  program  (so  that  It 
can  be  transformed).  To  be  a  program,  the  specification  language  must  have  a  formal 
semantics  (thus  precluding  pseudo-code  types  of  languages)  so  that  validity  of 
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transformations  and  of  the  development  process  Is  a  meaningful  concept. 

Since  the  motivation  of  this  Program  Manipulation  approach  Is  to  capture  and  record 
the  development  process,  It  Is  essential  that  the  specification  be  rather  directly  stated 
and  that  It  be  taken  as  the  starting  point  for  the  development.  Since  the  Intent  of  a 
specification  is  to  state  WHAT  is  required,  while  the  Intent  of  an  implementation  is  to 
state  HOW  those  requirements  are  to  be  satisfied  with  minimal  expenditure  of  computing 
resources,  quite  different  languages  for  specification  and  Implementation  are  Implied. 

This  wide  disparity  between  the  specification  and  Implementation  language  and  the 
avoidance  of  determining  HOW  requirements  should  be  satisfied  within  the  specification 
suggest  to  us  that  the  development  (embodied  as  a  sequence  of  transformations)  must 
bo  humanly  guided  (rather  than  automatically  generated),  because  such  global 
optimization  Issues  are  not  well-enough  understood  to  automate  (although  this  view  Is  not 
universally  held  [4,  6,  1 7]).  Thus,  we  have  constructed  an  Interactive  system  In  which  a 
usor  guides  the  system  by  specifying  which  transformations  the  system  should  apply. 
The  rest  of  this  report  Is  a  description  of  the  development  process  In  such  an  Interactive 
Program  Manipulation  system  (as  embodied  In  a  prototype  we  have  built)  through 
consideration  of  a  simple  example.  This  particular  example  was  chosen  to  be  simple 
enough  to  cover  within  this  report,  yet  complex  enough  to  demonstrate  the  type  of 
Issues  that  arise  during  development.  In  addition,  only  well-known  examples  were 
considered  so  that  the  one  chosen  did  not  have  to  be  explained  and  motivated. 

THE  PROBLEM 

Given  a  set  of  eight  Queens,  write  a  program  that  finds  a  way  of  positioning  them  on 
different  squares  of  a  chessboard  so  that  no  Queen  may  capture  any  other. 

THE  FORMAL  SPECIFICATION 

Before  the  development  processes  of  design  and  Implementation  can  begin,  the 
problem  must  be  expressed  In  a  formal  specification.  This  specification  should  express 
as  much  as  possible  WHAT  the  program  Is  to  do  without  expressing  HOW  It  Is  to  be 
accomplished.  The  WHAT  specification  will  then  be  systematically  converted  Into  a  HOW 
implementation  during  the  development  process. 

We  have  developed  a  formal  specification  language  [2]  in  which  this  problem  can  be 
directly  stated.  This  language  allows  the  definition  of  a  world  (Chess)  In  terms  of  the 
objects  (the  chess  board,  the  squares  of  which  it  is  composed,  the  rows  and  columns, 
the  various  chess  pieces,  etc.)  of  that  world,  the  relationships  that  may  exist  among 
those  objects  (the  Immediate  adjacency  of  two  squares,  the  squares  that  comprise  a 
row,  pieces  occupying  a  square,  etc.),  the  actions  that  exist  In  that  world  (placing  a 
piece  on  a  square,  moving  a  piece,  capturing  a  piece,  etc.),  the  constraints  that  the 
objects  of  the  world  must  satisfy  (two  pieces  can't  occupy  the  same  square),  and  the 
rules  of  inference  within  that  world  (a  piece  can  capture  another  If  It  can  move  to  the 
square  occupied  by  that  piece,  etc.).  These  declarations  define  the  environment  within 
which  the  program  will  operate.  An  Initial  configuration  of  the  objects  In  the  world  can  be 
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spoclfled  (In  this  case  that  the  chess  board  is  empty  [no  pieces  are  on  the  board]  and 
that  eight  queens  exist).  The  program  portion  of  the  specification  then  describes  either 
the  resulting  configuration  desired  (preferred)  or  the  behavior  desired  (acceptable). 
This  latter  option  Is  provided  because  many  real  tasks  cannot  be  simply  stated  In  terms 
of  a  goal  state,  but  rather  are  more  naturally  specified  In  terms  of  their  desired  behavior 
(such  as  a  payroll  system  that  periodically  issues  checks  satisfying  certain  criteria). 
These  behavioral  specifications  would  naturally  contain  as  much  "resulting  configuration" 
description  as  possible  so  as  to  least  constrain  the  ultimate  implementation.  As  the 
devolopment  proceeds,  the  "resulting  configuration"  portions  are  converted  Into  behavior 
specifications,  which  are  then  specialized  and  optimized. 

For  the  Eight  Queens  problem,  the  formal  specification  Is  shown  in  Figure  1.  For  the 
sake  of  conciseness  and  perspicuity  the  definition  of  objects,  relationships,  and  actions 
has  been  suppressed,  as  has  the  specification  of  the  initial  configuration  (which  defines 
the  structure  of  the  chess  board,  the  fact  that  no  pieces  are  on  any  of  the  squares,  and 
the  existence  of  eight  queens)  and  the  Inference  rule  defining  Queen-Capture. 

PROGRAMS: 

QUEENS:  [LAMBDA  {QUEEN-SEJ) 

(LOCAL  (BOARD-POSITION) 

(FOR  CK/££N  IN-SET  QUEEN-SETDO 

(DETERMINE  BOARD-POSITION  FROM 

(CHESS-BOARD  BOARD-POSITION)) 
(ASSERT  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITIONJ 


CONSTRAINT:  TWO-PIECES-CAN’T-OCCUPY-SAME-SQUARE 

PATTERN: (AND  (PIECE-ON-BOARD  PIECEHII  BOARD-POSITION) 
(PIECE-ON-BOARD  PIECEUfZ  BOARD-POSITION)) 
PATTERN-VARIABLES: (PIECE#1  PIECE#2  BOARD-POSITION) 

CONSTRAINT:  QUEEN-CANT-CAPTURE-ANOTHER-QUEEN 

PATTERN: (AND (PIECE-ON-BOARD  QUEEN^I  BOARD-POSITION^I) 
(PIECE-ON-BOARO  QUEENUfZ  BOARD-POSITION02) 
(QUEEN-CAPTURE  BOARD-POSTIONN1 
BOARD-POSTION02)) 

PATTERN.VARIABLES:(QUEEN«1  QUEEN<(2  BOARD-POSITION#! 

BOARD-POSIT I0N#2) 


Figure  1 


The  formal  specifications  Indicate  that  subject  to  two  constraints  (that  two  pieces 
can't  occupy  the  same  square  and  that  queens  cannot  be  placed  so  that  they  can 
capture  each  other),  each  queen  In  the  set  of  (presumably  eight)  queens  Is  to  be  placed 
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somovwhere  on  the  chess  board.  Although  this  specification  Is  not  the  most  abstract 
possible  (a  completely  "resulting  state"  specification  is  quite  straightforward),  and 
although  a  minor  Implementation  restriction  has  been  Imposed  (the  requirement  of  queens 
not  capturing  each  other  Is  only  logically  Imposed  on  the  resulting  solution  and  need  not 
necessarily  be  true  while  the  solution  Is  being  constructed,  as  Is  the  case  In  the  formal 
specification  of  Figure  1),  this  specification  has  been  chosen  to  reduce  the  amount  of 
unconventional  specification  constructs  considered  in  this  example. 

THE  DEVELOPMENT  PLAN 

The  development  of  this  specification  into  an  implementation  progressed  In  three  main 
phases:  explication,  reorganization,  and  representation  selection.  In  the  explication 
phase,  implicit  structures  within  the  specifications  are  made  explicit  and  constraints  are 
doalt  with  as  early  as  possible  in  an  attempt  to  gain  an  understanding  of  the  algorithmic 
structure  Implied  by  the  specification.  In  the  reorganization  phase,  the  sources  of 
computational  expense  are  identified  and  the  program  reorganized  to  mitigate  these 
expenses.  Representations  suitable  for  the  reorganized  programs  are  selected  In  the 
third  phase. 

This  phase-based  conceptualization  of  the  development  process  Is  not  yet  part  of  our 
prototype  system  and  Is  Introduced  here  tc  help  the  reader  understand  our  development 
plans.  We  theorize  that  In  more  complex  tasks  many  cycles  of  this  basic  plan  occur  (It  Is 
also  clear  that  the  representation  selection  may  precede  the  reorganization).  If  so,  then 
some  structure  must  exist  among  these  cycles.  Such  structure,  arising  partially  a  priori 
(plan)  and  partially  a  posteriori  (documentation),  represents  the  explanation  of  the 
development. 

Currently,  a  much  more  primitive  development  explanation  Is  maintained  by  the  system 
(see  Appendix  A).  It  consists  of  a  linear  sequence  of  state  descriptions.  Each 
description  Is  composed  of  the  state  name,  a  comment  entered  by  the  developer,  and 
the  action  taken  In  that  state  (such  as  applying  a  transformation  or  loading  the  Initial 
specification).  Structure  Is  added  to  the  linear  sequence  only  when  the  action  taken 
within  the  state  falls.  Development  proceeds  within  the  suspended  state  until  the  falling 
action  succeeds. 

For  the  development  explanation  shown  in  Appendix  A,  the  explication  phase 
corresponds  to  states  1  through  7,  the  reorganization  phase  corresponds  to  states  8 
and  9,  and  the  representation  phase  corresponds  to  state  10. 

THE  DEVELOPMENT  PROCESS 

The  development  of  the  Implementation  from  the  formal  specification  Is  described 
Informally  hero.  The  actual  form  of  the  program  at  each  step  Is  given  In  Appendix  B, 
which  is  organized  as  pairs  of  program  displays  that  highlight  (In  bold  face)  the  changes 
from  state  N  into  state  N'FI.  These  pairs  of  program  displays  are  produced  by  the 
system  as  part  of  the  automatic  documentation  of  a  development  [B]. 
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In  the  text  that  follows,  the  Informal  description  of  the  transition  Into  a  state  will  be 
preceded  by  its  state  description  as  given  In  Appendix  A. 

[Stste-2  (Unfold  both  constraints) 

(Apply  transformation:  Unfold-Constraint)] 

As  the  first  step  In  making  implicit  structures  explicit,  both  constraints  contained  in 
tho  original  formal  specifications  are  "unfolded.”  That  Is,  rather  than  relying  on  the 
Interpreter  of  the  language  to  check  the  constraints  after  each  (relevant)  operation  and 
to  backtrack  In  case  the  constraint  is  violated,  an  analysis  Is  performed  to  determine 
whoro  explicit  checks  should  be  Inserted  in  the  program  (after  assertions  that  could 
affect  the  truthfulness  of  the  constraint  predicate),  and  the  appropriate  checking  and 
backtracking  code  Is  added  there.  This  analysis  is  performed  by  the  unfold-constraint 
transformation.  As  part  of  its  analysis,  a  simplification  of  the  constraint  predicate  Is 
performed  (because  the  assertion  the  check  follows  will  be  true  and  need  not  be 
rochecked).  If  this  predicate  Is  satisfied,  then  the  constraint  has  been  violated  and  the 
coll  to  constraint-violation  Is  executed,  which  invokes  the  backtracking  mechanism  to 
renvoluate  the  most  recent  nondeterministic  statement  (the  choice  of  a  board  position  on 
which  to  place  the  Queen). 

Both  constraints  are  unfolded  by  this  transformation,  and  since  each  contains  two 
Instances  of  the  fact  being  asserted,  each  generates  two  checks  which  are  inserted  In 
the  program.  The  constraints,  having  been  unfolded,  are  removed  from  the  program. 

(S(A(e-3  (Simplify:  remove  redundant  unfolded  constraint  checks) 

(Manual  effort)] 

Because  of  tho  symmetry  that  existed  In  the  constraint  patterns,  one  of  the  two 
checks  generated  by  the  previous  transformation  for  each  constraint  Is  redundant.  The 
current  system  does  not  Include  an  automatic  simplifier,  so  either  transformations  for  this 
particular  type  of  simplification  must  be  applied  or  else  the  redundant  code  must  be 
manually  removed.  The  latter  option  was  chosen  to  Illustrate  this  facility  within  the 
system. 

It  Is  assumed  that  situations  will  inevitably  arise  for  which  the  appropriate 
transformation  does  not  already  exist  within  the  catalog.  Therefore,  the  developer  may 
either  define  a  new  transformation  (thus  extending  the  catalog)  or  modify  the  program 
directly  through  an  Interactive  editor  (I.e.,  manually  modify  the  program).  It  must  be 
recognized  that  both  options  result  in  an  unvalidated  modification  of  the  program  (merely 
defining  a  transformation  does  not  ensure  its  validity).  In  both  cases  the  unvalideted 
stop  becomes  part  of  the  documentation  of  the  development,  which  can  later  be 
reviewed  by  the  others  and  Judged  acceptable  or  not. 

The  redundancy  of  the  first  pair  Is  based  on  simple  renaming  of  free  variables,  while 
the  second  also  depends  upon  determining  that  Queen-Capture  Is  a  symmetric  relation. 
The  second  element  of  each  pair  of  checks  was  manually  edited  out  of  the  program. 
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[State-4  (Make  backtracking  explicit  so  that  it  can  be  minimized) 

(Apply  transformation:  Unfoid-Consequential-Backtracking)] 

The  second  step  In  making  Implicit  structure  explicit  Is  now  attempted  by  applying  the 
transformation  to  unfold  backtracking  (other  backtracking  transformations  can  be  found 
In  references  [10,  13]).  This  transformation  converts  the  Implicit  control  structure 
nocossery  to  support  resumption  of  control  at  a  nondeterminism  point  from  an  arbitrary 
failure  into  a  format  in  which  the  nondeterminism  Is  embedded  In  an  iterative  loop  through 
all  the  possibilities  searching  for  an  acceptable  one  as  determined  by  the  loop  body 
containing  all  the  possible  failure  points  reexpressed  as  loop  continuation  statements. 

The  activation  pattern  for  this  transformation  assumes  a  recursive  format  for  the 
routine  containing  the  nondeterminism.  Unfortunately,  when  the  transformation  Is  applied 
to  the  program  In  State-3,  this  activation  pattern  fails  to  match.  This  causes  the  system 
to  ask  the  developer  whether  he  would  like  to  modify  ("jitter”)  the  program  so  that  the 
activation  pattern  will  match  or  abort  the  application  of  the  current  transformation.  The 
developer  responded  that  Jittering  was  desired.  The  system  then  enters  a  subgoaling 
mode  In  which  further  development  proceeds  under  the  direction  of  the  developer  until 
tho  suspended  activation  pattern  successfully  matches  the  modified  program.  At  that 
point  the  development  pops  out  of  the  subgoal  mode  and  continues  application  of  the 
suspended  transformation. 

[State-4-l  (Convert  iteration  to  recursion) 

(Jitter  transformation:  Make-set-iteration-recursive)] 

In  tho  subgoal  development  the  developer  applies  a  transformation  (recorded  as  a 
jitter  transformation  because  the  developer  Is  attempting  to  get  the  program  to  conform 
to  the  requirements  of  a  suspended  transformation)  that  converts  the  Iteration  to  a 
recursion. 

It  Is  instructive  to  digress  for  a  moment  and  consider  In  detail  the  application  of  this 
transformation,  which  Is  shown  in  Figure  2.  The  transformation  contains  a  comment,  an 
activation  pattern,  a  list  of  modifications  and  declaration  of  variables  used  within  the 
transformation.  In  addition.  It  could  contain  properties  that  the  program  and/or  data  had 
to  satisfy  In  order  for  the  transformation  to  be  applicable  or  properties  known  to  be  true 
aftor  the  transformation  was  applied. 

The  pattern  contains  variables  and  literals  (all  names  not  declared  to  be  variables). 
Tho  variables  will  be  matched  against  a  single  expression  in  the  program  to  which  the 
transformation  Is  applied  or  against  a  .sequence  of  expressions  (if  the  variable  begins 
with  an  exclamation  mark).  When  this  pattern  is  applied  to  the  program  In  State-3,  a 
unique  match  is  found  In  which  5ET1  Is  bound  to  QUEEN-SET,  P2  Is  bound  to 
(BOARD-POSITION),  tho  segment  variable  !S1  Is  bound  to  everything  following  the  DO  In 
tho  FOR  statement  (the  DETERMINE  and  inner  LOCAL  statements),  etc.  If  more  than  a 
single  match  were  found,  the  developer  would  have  been  asked  which  match  to  use.  If 
no  match  were  found,  the  developer  would  have  been  asked  whether  the  program  should 
be  jittered  or  the  transformation  aborted. 


AN  EXAMPLE 
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MAKE-SET-ITERATION-RECURSIVE 


COMMENT:  CONVERT  SIMPLE  SET  ITERATION  THROUGH  THE  (ONLY) 

PARAMETER  INTO  A  RECURSION 

PATTERN:  [LAMBDA  iSET  1) 

(LOCAL  P2  (FOR  Of  IN-SET  SET1  DO  !S1) 

!S2] 

MODIFICATIONS:  [iBINDRI  FRO/WFNAtlE) 

(BIND  P3  FROM  (CONS  Of  P2) ) 
{REPLACE-PATTERN 
((LAMBDA  (S£Tf) 

(LOCAL  P3  (TERMINATION-TEST: 

(IF  (EMPTY  SETf) 

THEN 

IS2 

(RETURN))) 

(REMOVE  01  FROM  SET  1) 

•SI 

(RECURSIVE-CALL:  («f  SETfl 
PATTERN-VARIABLES:  (SETf  !S1  Of  P2  !S2  P3  R1) 


Figure  2 


Following  the  pattern  match,  the  applicability  properties  to  be  satisfied  are  checked 
(there  are  none  in  this  transformation).  These  properties  fall  Into  two 
categories — properties  that  must  be  satisfied  before  the  transformation  can  be  applied 
and  properties  that  eventually  must  be  satisfied  to  validate  the  applicability  of  this 
transformation  but  need  not  be  considered  immediately.  Such  properties  are  quite 
Important  because  they  build  up  "requirements"  on  the  program  and/or  data  that  must 
eventually  be  satisfied,  but  that  because  they  can  be  delayed,  can  be  used  as  guidance 
for  the  subsequent  development.  If  any  immediate  properties  were  not  satisfied,  then 
the  system  would  attempt  to  prove  them  (currently  only  through  special-purpose 
property  provers).  Falling  that.  It  would  enter  a  subgoaling  mode  until  further 
development  established  the  Immediate  property. 

After  the  applicability  properties  are  satisfied  (or  delayed),  the  modifications  are 
performed.  These  modifications  are  a  linear  sequence  of  actions.  The  prototypical 
action  Is  to  replace  the  portion  of  the  program  matched  by  the  applicability  pattern  with 
some  new  pattern  composed  of  literals  and  variables.  The  variables  used  In  this 
replacement  pattern  can  be  either  bound  by  the  applicability  pattern  (such  as  8ET1 )  or 
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ones  calculated  from  those  variables  (such  as  R1  and  P3)  through  the  BIND  action.  This 
sequence  of  BIND  actions  calculating  new  values  that  become  part  of  the  replacement 
pattern  Is  quite  typical  of  the  transformations  we  have  studied  (and  separates  them  from 
simpler  so  called  "syntactic"  transformations  Involving  only  pattern  replacement). 

In  addition  to  these  actions,  other  transformations  can  be  applied  (providing  a  means 
to  package  transformations),  arbitrary  functions  Invoked,  or  a  simple  plan  established 
through  goals  to  be  achieved. 

In  the  current  transformation,  the  BIND  action  Is  used  to  calculate  values  for  the 
recursive  call  of  the  program  being  transformed  (In  variable  R1)  and  for  the  addition  of 
the  program  Iteration  variable  (QUEEN)  to  the  declaration  of  variables  In  the  LOCAL 
statement  (In  the  transformation  variable  P3).  These  values  are  then  used,  along  with 
several  found  directly  by  the  applicability  pattern,  to  form  the  replacement  pattern. 

The  resulting  program  has  annotations  In  the  form  of  labels  (names  ending  with  a 
colon),  which  describe  the  teleological  function  of  that  portion  of  the  program  [16]. 
These  annotations  may  well  help  later  transformations  access  and  analyze  appropriate 
parts  of  the  program.  But  as  these  annotations  are  currently  part  of  the  program  text, 
they  must  be  dealt  with  by  succeeding  transformations  whether  they  are  Interested  In 
those  annotations  or  not.  This  has  proved  most  bothersome.  One  solution  used  In  the 
MENTOR  system  [1 1]  Is  to  place  these  annotations  Into  orthogonal  dimensions  accessible 
only  by  special  commands  so  that  the  annotations  are  Invisible  for  those  uninterested. 
Wo  expect  to  employ  this  solution  for  all  annotations  Including  the  maintenance  of 
properties. 

After  applying  the  Jittering  transformation  of  State  4-1,  the  modified  program 
successfully  matches  the  applicability  pattern  of  the  suspended  unfold- 
consoquentlal-backtracking  transformation,  and  so  processing  of  this  transformation  Is 
resumed.  The  transformation  (shown  In  Figure  3)  Is  similar  In  structure  to  the  previous 
transformation  as  Its  modifications  consist  of  a  series  of  BIND  actions  followed  by  a 
REPLACE-PATTERN  action.  Unlike  the  previous  transformation,  this  one  contains  some 
NECESSARY-PROPERTIES  that  must  be  satisfied  before  the  transformation  can  be 
applied.  The  properties  are  arbitrary  predicates  applied  to  the  various  objects  of  the 
system  being  Implemented  (such  as  Its  programs,  code  segments,  and  data  structures). 
In  this  transformation  there  are  four  instances  of  the  same  property  applied  to  single 
(but  different)  arguments  consisting  of  a  code  segment  Identified  by  the  match  of  the 
transformation-applicability  pattern.  Aside  from  a  small  number  of  bullt-ln  properties 
directly  relating  to  the  semantics  of  the  specification  language  (and  produced  and 
maintained  by  an  analysis  package  soon  to  be  Incorporated  within  the  system),  all  other 
properties  must  either  be  defined  In  terms  of  other  properties  (theorem-proving 
techniques  will  be  used  to  determine  whether  or  not  the  property  Is  satisfied)  or 
self-defined  through  direct  generation  as  the  result  (the  KNOWN  property)  of  some 
transformatlon(s)  and/or  deduction  through  special-purpose  property  provers.  Typically 
for  self-defined  properties,  no  explicit  formal  definition  exists. 


AN  EXAMPLE 


0 


UNFOLD-CONSEQUENTIAL-BACKTRACKING 


COMMENT:  MAKE  BACKTRACKING  EXPLICIT 

PATTERN:  (LOCAL  VI  (TERM  I  NAT  I  ON- TEST:  (IF  THEN  IS8  (RETURN))) 

!S1 

(DETERMINE  01  FROM  PI) 

!S2 

(RECURSIVE-CALL:  S3) 

!S4) 

NECESSARY  PROPERTIES:  ( (CQNSEQUENTIAL-NDN-DETERMINISM-FREE  /SI) 

(CONSEQUENT I AL-NDN-DETERMI NI BM-FREE  !S2) 

(CONSEQUENT  I AL -NON-DETERM I N I SM-FREE  /S4) 
(CONSEQUENTIAL -NON-DETERMINISM-FREE  /S5) ) 

MODIFICATIONS;!  (B//VO  /S2*  FROM 

(UNFOLD-CONSEQUENTIAL-BACKTRACKING-BUILDER  /S2) ) 
[BIND  /S2UNDO  FROM  (UNDQ-OF  (ACTI VE-PREDECESSORS-DF 

NIL  /S2) 

[BIND  IS1UNDO  FROM  (UNDO-OF  (ACTI VE-PREDECESSORS-DF 

NIL  ISI) 

[BIND  ISS*  FROM  (UNFOLO-CONSEQUENT I  AL -BACK  TRACKING-BUILDER 
/S5T)) 

[REPLACE-PATTERN 

[  (LOCAL  l^f  (TERMINATION-TEST;  (IF  P2  THEN  ?S5* 

(EXIT  SUCCESSFUL))) 

I  SI 

(FOR  ALL  PI  THERE  IS  IS2* 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  S3) ) 

THEN 

(LOOF’-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS:  IS2UNDO) 

(LOOP-RETURN  FORCE-ANOTHER-CHDICE) ) 

THEN 

!S4 

(EXIT  SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS:  /S1UNDO) 

(EXIT  UNSUCCESSFUL] 


PATTERN  VARIABLES:  (/Sf  !S2  IS4  !S2*  /S2UNDO  IS1UNOO  VI  P2  Pi 

S3  01  !SS*  IS5) 
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The  property  (CONSEQUENTIAL-NON-DETtRMINISM-FREE)  used  In  this  transformation  Is 
defined  only  through  Its  special-purpose  property  prover.  Informally,  the  property  means 
that  the  code  segment  to  which  It  Is  applied  does  not  contain  any  "meaningful" 
nondeterminism.  This  Is  Important  because  this  transformation  rearranges  the  program  so 
that  any  "backtracking  point"  Is  part  of  the  still  active  loop;  backtracking  can  then  be 
accomplished  by  merely  continuing  that  loop  (after  undoing  any  actions  taken  within  the 
loop).  It  assumes  that  only  one  such  backtracking  point  exists,  and  uses  the  property  to 
validate  this  assumption.  The  concern  is  that  only  a  single  backtracking  point  exists  and 
the  existence  of  "Incidental"  nondeterminism  is  of  no  consequence.  In  the  program  of 
State  4-1  there  are  two  nondeterministic  statements,  the  selection  of  a  queen  and  the 
detormlnation  of  where  to  place  it  on  the  chessboard.  The  first  of  these  Is  Incidental  in 
that  It  doesn't  matter  which  queen  Is  selected.  But  the  second  is  consequential 
because  the  course  of  subsequent  processing  Is  highly  dependent  upon  the  choice 
made.  Thus,  in  backtracking,  only  the  nondeterminism  of  the  selection  of  a  board  position 
should  be  considered  as  the  other.  Incidental  choice  of  a  queen  doesn't  affect  the 
subsequent  processing. 

After  the  applicability  pattern  of  the  transformation  has  been  matched,  the  system 
attempts  to  verify  that  the  necessary  properties  are  satisfied.  The  first  property  is 
CONSEQUENTIAL-NON-OETERMINISM-FREE  applied  to  the  segment  !S1  which  is  bound  to 
the  statement  (REMOVE  QUEEN  FROM  QUEEN-SET).  The  method  of  verifying  this  property 
Is  to  Invoke  Its  special-purpose  property  prover,  which  falls  because  It  is  unable  to  tell 
that  this  nondeterminism  Is  incidental.  Because  a  necessary  property  couldn't  be 
verified,  the  system  enters  a  subgoal  mode  (through  a  self-generated  ACHIEVE  command 
resulting  In  State  4-2)  under  which  further  development  will  continue  until  the  necessary 
property  Is  achieved.  An  appropriate  message  to  this  effect  Is  given  to  the  developer. 

[Statr  4-2'i  (Mark  "REMOVE”  as  incidental  nondeterminism) 

(Apply  transformations:  Mark-incidental-non-determinism)] 

The  developer  responds  to  this  problem  by  applying  a  transformation  that  marks  the 
REMOVE  statement  as  Incidental  (by  converting  It  to  REMOVE*).  This  transformation  has 
a.s  a  required  property  that  the  choice  of  the  object  being  removed  (Queen)  Is  Incidental. 
Since  this  is  a  required  rather  than  an  immediate  property,  It  need  not  be  verified 
Immediately,  and  so  It  Is  added  as  an  UNPROVED-PROPERTY  of  the  current  state.  Such 
properties  must  be  either  proved  (by  one  of  the  methods  described  previously)  or 
claimed  (assumed  by  the  user  to  be  true)  before  the  development  Is  completed.  Any 
claims  (developer  assumptions)  become  part  of  the  documentation  of  the  development. 

After  each  step  of  the  development  In  the  subgoal  mode,  the  system  attempts  to 
dotormlne  whether  the  property  to  be  achieved  can  be  verified.  Here,  the  appropriate 
method  Is  to  reInvoke  the  special-purpose  property  prover  on  code  segment  !S1. 
j  However,  the  transformation  Just  applied  modified  this  code  segment  and  the  new  value 

'  must  be  used.  This  Is  accomplished  by  rematchIng  the  suspended  applicability  pattern  to 

obtain  the  appropriate  code  segment.  In  fact,  since  the  subgoal  development  logically 
precedes  the  suspended  transformation,  the  suspended  transformation  Is  reprocessed 
after  each  subgoal  development  step. 

j 

! 


with  !S1  rebound  to  (REMOVE*  QUEEN  FROM  QUEEN-SET),  the  special-purpose  property 
prover  Is  successful  In  verifying  the  CONSEQUENTIAL-NON-DETERMINISM-FREE  property. 

Verification  of  the  first  Instance  of  the  CONSEQUENTIAL-NON-DETERMINISM-FREE 
property  completes  the  processing  of  the  subgoal  ACHIEVE  state,  and  processing  of 
State  4  resumes  with  attempts  to  verify  the  other  Instances  of  this  property,  all  of  which 
succeed. 

Processing  then  continues  with  the  modificstlon  steps.  The  second  and  third  BIND 
actions  find  the  active  statements  within  some  code  segment  and  then  build  a  sequence 
that  undoes  their  effects  (so  that  when  control  Is  returned  to  the  ''backtracking  point" 
[now  In  the  form  of  an  interactive  loop]  the  program  state  has  been  restored  to  Its  state 
when  control  was  last  there).  The  first  and  last  BIND  actions  locate  any 
CONSTRAINT-VIOLATION  statements  occurring  In  the  program  and  replace  them  by  the 
undo  of  the  active  statements  preceding  the  CONSTRAINT-VIOLATION  statement  (and 
following  the  nondetermlnistic  choice)  followed  by  a  loop  continuation  statement  (to  the 
loop  being  Introduced  by  this  transformation).  After  all  the  BIND  actions  have  been 
processed,  the  replacement  pattern  Is  constructed  and  substituted  for  the  portion  of  the 
program  matched  by  the  transformation's  applicability  pattern. 

(State  5  (Assimilate  constraint  into  generator) 

(Apply  transformation:  Assimilate-test-in-thesis-loop)] 

The  final  stage  In  explicating  the  underlying  structure  of  the  algorithm  Is  to 
Incorporate  Into  Its  selection  the  constraints  that  a  board  position  must  satisfy.  Here, 
those  constraints  are  tested  after  a  queen  Is  placed  on  the  board  at  the  selected 
position  (because  the  constraints  were  originally  stated  In  terms  of  pieces  on  the  board), 
and  If  the  position  Is  unacceptable,  then  the  queen  Is  removed  from  the  board  and 
another  selection  made.  In  general,  more  efficient  processing  results  when  a  selection  Is 
based  on  all  such  restrictions  that  It  must  satisfy.  Toward  this  end,  the  developer 
attempts  to  apply  a  transformation  to  assimilate  one  of  these  restrictions  Into  the 
generator  of  board  positions.  (This  same  transformation  will  be  applied  again  to  assimilate 
the  other  restrictions.)  Unfortunately  the  applicability  pattern  of  this  transformation 
requires  that  the  restriction  being  assimilated  be  the  first  statement  of  the  body  of  the 
f  »r-loop  In  which  the  generator  occurs,  and  this  falls  to  match  the  program.  As  before, 
the  system  asks  the  developer  whether  Jittering  Is  desired,  and  when  affirmed.  Initiates 
a  subgoal  development  (which  will  take  several  steps  before  the  suspended  applicability 
pattern  can  be  matched). 

[Slate  5-1  (Merge  the  locals) 

(Jitter  transformation:  Merge-locals)] 

As  the  first  step  In  the  Jittering  process,  the  developer  attempts  to  merge  the  LOCAL 
Inside  the  for-loop  with  the  outer  LOCAL.  Again  the  applicability  pattern  falls  because 
the  two  LOCALS  being  merged  must  be  separated  by  only  a  single  level  of  nesting  (here 
tho  Inner  LOCAL  Is  Inside  the  for-loop,  which  Is  inside  the  LOCAL),  and  so  (after 
confirmation  by  the  developer)  another  level  of  Jittering  Is  Initiated. 
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(State  5*1-1  (Extract  LOCAL  from  for*loop) 

(Jitter  transformation:  Extract-local-froin-for-loop)] 

The  developer  applies  a  transformation  that  extracts  the  LOCAL  from  within  the 
for-loop.  This  transformation  enables  the  suspended  applicability  pattern  of  the 
Merge-locals  transformation  to  succeed  and  so  ends  this  level  of  jittering. 

The  suspended  applicability  pattern  matched  the  Jittered  program  and  the 
transformation's  modification  steps  are  performed.  First  a  BIND  statement  Is  used  to 
calculate  the  combined  set  of  variable  declarations,  and  then  the  replacement  pattern  is 
formed  which  contains  the  combined  declarations  and  In  which  the  statements  of  the 
Inner  LOCAL  are  embedded  within  the  outer  one.  (As  noted  previously,  the  current  system 
does  not  yet  employ  orthogonal  annotation  dimensions  [11].  Here  the  LOCAL  statements 
are  used  solely  to  scope  variables.  If  this  variable  scoping  were  handled  as  an 
annotation  It  would  not  Impede  the  development  as  It  does  here.) 

[State  5-3  (Move  constraint  test  ahead  of  assertion) 

(jitter  transformation:  Move-constraint-uphill)] 

The  restriction  has  now  been  moved  to  the  top  level  of  the  for-loop  body,  but  It 
follows  the  assertion  (rather  than  preceding  it,  as  required  by  the  suspended  assimilation 
applicability  pattern).  The  developer  applies  the  Move>constralnt-uphlll  to  Interchange 
tho  order  of  the  restriction  and  the  assertion  preceding. 

To  Interchange  these  two  statements,  their  mutual  Interactions  must  be  revised  to 
select  the  new  ordering.  This  leaves  the  assertion  unchanged  since  It  has  no 
dopendonce  on  the  restriction.  However,  both  the  predicate  and  body  of  the  restriction 
must  (In  general)  be  updated  tc  reflect  knowledge  of  the  existence  of  the  assertion  that 
now  follows  them.  Thus,  If  the  predicate  depended.  In  part,  on  the  existence  of  the 
assertion.  It  must  be  modified  to  Incorporate  this  dependence  without  actually  accessing 
tho  data  (because  It  will  not  yet  exist).  In  the  current  case,  the  predicate  Is 
Independent  of  the  assertion,  and  so  Is  not  changed.  On  the  other  hand,  the  THEN  clause 
denies  the  assertion  before  forcing  another  Iteration  of  the  selection  loop,  and  thus.  Is 
highly  dependent  upon  the  assertion.  The  semantics  of  the  program  Is  maintained  If  the 
denial  Is  removed  (whenever  another  Iteration  Is  forced,  the  assertion  will  not  exist). 
Those  modifications  to  the  program  are  calculated  by  special-purpose  analysis  routines 
(callod  as  part  of  the  transformation's  BIND  actions).  Incorporated  Into  the  replacement 
pattern,  and  substituted  Into  the  program. 

[State  5*5  (Simplify:  suppress  null  else  clause) 

(jitter  transformation:  Else-suppression)] 

Although  the  restriction  Is  now  in  the  right  location  (as  the  first  statement  in  the 
for-loop  body),  the  suspended  applicability  pattern  still  doesn't  match  because  It 
requires  the  restriction  to  be  an  IF-THEN  statement  (with  no  ELSE  clause),  and  this 
restriction  has  an  ELSE  clause  whose  body  is  NIL. 
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The  fact  that  this  match  falls  because  of  this  trivial  problem  points  up  two  difficulties 
with  the  current  system.  First,  no  automatic  simplification  exists.  Such  simplification 
would  (If  It  existed)  certainly  have  removed  this  null  ELSE  clause  when  it  was  created 
(by  the  unfold-constraint  transformation  in  State  2).  Second,  given  that  a  simple 
mismatch  exists  between  the  applicability  pattern  and  program,  rather  than  have  Jittering 
be  a  manual  process  (as  it  currently  Is),  the  system  should  automatically  Jitter  the 
program  so  that  the  desired  transformation  can  be  applied  (we  are  working  to  resolve 
both  these  deficiencies).  Here,  the  developer  had  to  apply  a  simplification 
transformation  to  remove  the  null  ELSE  clause.  This  modification  enabled  the  suspended 
applicability  pattern  to  succeed,  and  so,  processing  of  the  Jittering  subgoal  development 
Is  completed. 

The  suspended  applicability  pattern  succeeds,  and  the  replacement  pattern  is  formed 
by  composing  a  new  loop  predicate  consisting  of  the  conjunctions  of  the  old  loop 
predicate  and  the  negation  of  the  restriction  predicate.  The  rest  of  the  restriction  (the 
IF-THEN  structure  and  the  body  of  the  THEN  clause)  is  deleted  and  Its  semantics  are  now 
part  of  the  loop  itself. 

[Slatp  6  (A.tsimilale  remaining  constraint  into  loop  generator) 

(Apply  transformation:  Assimilate-test-in-thesis-loop)] 

The  sequence  of  State  5  (without  having  to  bother  with  the  LOCALs)  Is  repeated 
(Interchanging  the  order  of  the  restriction  and  the  assertion,  and  suppressing  the  null 
ELSE  clause)  to  Incorporate  the  remaining  restriction  Into  the  loop  generator. 

(State  7  (Simplify:  remove  embedded  AND  In  loop  generation) 

(Apply  transformation:  Simplify^AND)] 

The  embedded  conjunction  within  the  loop  predicate  Is  merged  with  the  outer 
conjunction.  Automatic  simplification  would,  when  added  to  the  system,  remove  the  need 
for  this  step. 

[State  8  (Maintain  acceptable  board  positions  incrementally) 

(Apply  transformation:  Calculate>predicatc-incrementally)] 

The  simplification  performed  In  the  previous  state  completes  the  explication  phase  of 
the  development  whose  purpose  was  to  reveal  the  underlying  structure  of  the  algorithm 
Implicit  In  the  original  specification.  This  structure  is  quite  clear  In  State  7.  A  simple 
recursive  program  exists  In  which  on  each  recursive  level,  a  queen  is  removed  from  the 
set  of  queens  and  placed  on  a  position  on  the  chess  board  not  already  occupied  and  not 
capturable  by  any  queen  already  on  the  chess  board.  The  recursion  Is  then  carried  out 
at  the  next  level  and  If  It  (and  all  Its  recursive  calls)  Is  successful,  the  algorithm 
terminates.  If  not,  the  queen  Is  removed  from  the  board  and  another  position  selected. 

The  computationally  expensive  part  of  this  algorithm  Is  finding  an  acceptable  board 
position.  The  developer  recognizes  that  this  same  calculation  (In  a  slightly  altered 
environment  with  an  extra  queen  placed  on  the  board)  Is  carried  out  at  each  level,  and 
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decides  that  rather  than  repeat  these  simitar  calculations,  the  set  of  acceptable  board 
positions  should  be  maintained  Incrementally.  That  Is,  as  actions  affecting  the 
membership  of  the  set  occur  within  the  program,  appropriate  maintenance  actions  are 
Inserted  to  update  the  set  membership  accordingly.  The  actions  that  can  affect  set 
membership  are  the  assertion  and/or  denial  of  facts  which  Interact  with  the  set 
definition  predicate.  Such  statements  are  either  preceded  (assertions)  or  followed 
(denials)  by  the  necessary  maintenance  actions.  Furthermore,  the  Iteration  through  the 
elements  of  the  set  Is  changed  from  a  generative  format  (FOR  ALL  <prodlcato>...)  to 
simple  membership  In  a  preexisting  set  (FOR  <X>  IN-SET  <set>...). 

These  modifications  are  all  made  automatically  by  the  Calculate- 
predlcate-lncrementally  transformation.  The  calculation  of  the  precise  predicate  to  use 
to  update  the  set  membership  Is  quite  complex  (see  [3]  for  the  details  and  [15]  for  the 
foundations  of  these  Ideas),  but  the  general  Idea  Is  straightforward:  given  the  newfound 
truth  (or  falseness)  of  a  fact,  what  else  must  necessarily  be  true  to  make  the  set 
definition  pattern  change  Its  value  (that  Is,  become  true  or  become  false,  or  equivalently, 
to  have  the  support  of  the  corresponding  set  elBment(s)  change)  and  to  ensure  that  no 
other  support  exists  for  these  elements?  That  Is,  what  must  be  true  to  detect  the 
creation  of  the  first  support  of  an  element  or  the  deletion  of  Its  last  support?  Only  then 
should  it  be  added  to,  or  deleted  from,  the  set. 

For  the  set  of  board  positions,  this  maintenance  predicate,  following  the  placement  of 
a  queen  on  the  board  or  Its  removal,  Is  determined  to  be  the  set  of  board  positions  that 
are  on  the  chess  board,  are  not  occupied  by  any  other  piece,  ARE  capturable  by  the 
queen  being  placed  on  the  board  or  removed  from  It,  and  are  not  capturable  by  any  other 
quoen  already  on  the  board. 

Actually,  since  the  PIECE-oN -BOARD  pattern  occurs  twice  In  the  set  definition 
predicate,  two  maintenance  action  loops  are  generated.  The  first  of  these  Is  concerned 
only  with  the  position  occupied  by  the  queen  (or  about  to  bo  occupied  by  It),  while  the 
second  maintenance  loop  Is  the  one  described  above. 

[State  9  (Simpliry:  remove  redundant  loop  from  maintenance  actions) 

(Manual  effort)] 

The  single  position  handled  by  the  first  maintenance  loop  Is  also  handled  by  the 
second,  more  general,  loop.  It  Is  therefore  redundant,  and  the  developer  used  the  editor 
to  manually  remove  the  first  maintenance  loop  (both  the  occurrence  preceding  the 
assertion  and  the  occurrence  following  the  denial). 

[State  10  (Pick  a  representation  for  board  positions) 

I  (Manual  effort)] 

State  9  completes  the  reorganization  phase  of  the  development  accomplished  by 
deciding  to  employ  Incremental  set  maintenance.  The  final  phase  deals  with  determining 
j  ropresontatlons  appropriate  for  the  processing.  At  this  stage,  the  expensive  part  of  the 

processing  is  determining  within  the  maintenance  actions  whether  particular  positiona  are 

i 

I 
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capturable  by  any  queen.  Is  there  a  representation  In  which  this  operation  can  be  more 
easily  performed? 

The  time  has  come  for  the  developer  to  Introduce  a  little  creative  magic  (It  is  at  Just 
those  points  that  a  purely  automatic  approach  seems  most  suspect).  By  switching  the 
viewpoint  from  positions  to  lines  (I.e.,  rows,  columns,  and  diagonals)  the  problem  Is 
greatly  simplified.  That  Is,  rather  than  Incrementally  maintaining  the  set  of  remaining 
board  positions  explicitly,  the  set  of  remaining  lines  Is  Incrementally  maintained  and  the 
remaining  board  positions  are  generated  from  them  (as  the  Intersection  of  four  of  the 
remaining  lines:  a  row,  a  column,  and  two  diagonals).  In  this  representation,  maintaining 
the  sot  of  remaining  lines  when  a  queen  Is  placed  on  the  board  (or  removed  from  It) 
merely  involves  deleting  (or  adding)  the  corresponding  lines  (the  row,  the  column,  and 
two  diagonals)  without  any  search.  Furthermore,  the  Iteration  through  the  remaining 
board  positions  becomes  a  quadruply  nested  loop  through  the  remaining  rows,  columns, 
and  left  and  right  diagonals  finding  four  lines  that  intersect  at  a  single  position.  Since  a 
position  Is  uniquely  determined  by  a  row  and  column,  the  Inner  two  loops  can  be  replaced 
by  checks  of  whether  the  corresponding  diagonals  remain. 

These  modifications  produce  the  program  In  State  10.  It  was  produced  by  manual 
editing,  but  wo  are  Investigating  how  this  step  can  be  formulated  as  a  representation 
alteration  transformation  (called  type  transformations  [19]). 

REMAINING  OPTIMIZATIONS 

A  few  steps  remain  to  complete  the  optimization  and  convert  the  program  Into 
conventional  form.  They  Include  removing  the  outer  loop  through  the  rows  (since  each 
row  must  have  a  queen  and  failure  to  place  a  queen  in  a  row  cannot  be  resolved  by 
reconsidering  that  row  again  later),  eliminating  the  use  of  the  set  of  queens  used  only  to 
determine  termination  (by  using  any  one  of  the  other  sets  which  become  empty  at  the 
same  time),  explicitly  collecting  the  set  of  queen  placements  as  the  result  of  the 
computation  rather  than  having  it  be  implicit  In  the  set  of  assertions  In  the  data  base, 
and  using  lists  (or  arrays)  Instead  of  sets. 

We  have  not  yet  worked  on  these  optimizations  pending  resolution  of  the 
representation  selection  Issue. 

CONCLUSIONS 

Using  a  transformation  system  to  develop  the  Implementation  of  a  small,  but  nontrivial 
example,  such  as  the  Eight  Queens  problem  presented  here.  Is  both  instructive  and 
disconcerting. 

Developing  an  Implementation  through  the  application  of  formalized  transformations 
forces  a  more  careful  consideration  of  the  strategy  to  be  employed,  and  the  tradeoffs 
Involved.  This  highly  beneficial  result  represents  a  shift  In  focus  away  from  maintaining 
consistency,  which  almost  completely  consumes  today's  programmers,  toward  a  concern 
with  tradeoffs  between  alternative  implementations.  With  the  system  assuming  the 


responsibility  for  maintaining  consistency,  the  developer  should  be  free  to  concentrate 
on  these  higher  level  Issues.  Such  consideration  of  the  Implementation  tradeoffs 
heightens  the  need  for  adequate  specifications  that  merely  define  the  required  behavior 
without  determining  how  It  Is  to  be  achieved. 

However,  It  Is  quite  evident  from  the  development  presented  here  that  the  developer 
has  not  been  freed  to  consider  Implementation  tradeoffs.  Instead  of  a  concern  for 
mointolnlng  consistency,  the  equally  consuming  task  of  directing  the  low-level 
development  has  been  Imposed.  While  the  correctness  of  the  program  Is  no  longer  an 
Issue,  keeping  track  of  both  where  one  Is  In  a  development  and  how  to  accomplish  each 
step  In  all  Its  fine  detail  diverts  attention  from  the  tradeoff  question. 

It  la  quite  clear  that  If  transformation  systems  are  to  become  useful,  this  difficulty 
must  be  removed.  Automatic  simplification  and  Jittering,  as  discussed  In  this  report,  will 
holp  considerably  (see  also  [12]).  But  equally  important  Is  the  ability  to  state, 
roprosont,  refine,  and  display  Implemention  plans.  The  current  lack  of  an  adequate 
framework  In  which  the  development  proceeds  Is  a  major  source  of  conceptual  overload. 

Major  Improvements  are  also  needed  In  the  documentation  of  developments  to  make 
thorn  understandable.  The  ability  to  highlight  changes  between  successive  states,  as 
illu.strated  In  Appendix  B,  Is  but  a  first  step.  The  structure  of  the  development  plan  must, 
become  an  Integral  part  of  Its  documentation  and  understanding. 

Finally,  If  Implementation  tradeoffs  are  to  gain  prominence,  and  If  systems  developed 
via  transformations  are  to  be  maintained,  the  ability  must  be  created  to  replay  a  slightly 
altered  development  (I.e.,  the  altered  development  becomes  the  implementation  plan  to 
be  carried  out  largely  or  completely  automatically). 

All  of  the  above  benefits  and  problems  are  present  only  on  the  assumption  that  people 
are  Involved  In  the  development  process.  If  this  process  were  tptally  automated,  then 
none  of  these  Issues  would  arise.  However,  given  the  growing  concern  with  starting  a 
dovolopment  from  a  very  high-level  (and  largely  noncomputatlonal)  specification,  and  the 
paucity  of  Information  known  about  strategic  optimization  that  is  central  to  Implementing 
such  specifications,  it  seems  unlikely  that  fully  automatic  systems  could  deal  effectively 
with  such  specification  languages.  Rather,  one  would  expect  to  see  a  gradual  raising  of 
tho  level  of  the  languages  that  can  be  automatically  optimized.  Thus,  the  role  of 
Interactive  transformation  systems  will  be  to  provide  a  validated  mapping  between  tho 
high-level  specifications  and  the  "programming  language"  from  which  automatic 
optimization  can  proceed. 
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(STATE-1  (ENTER  SPECIFICATION  FOR  EIGHT  QUEENS  PROBLEM) 

(LOAD  FILE  EIGHT -QUEENS. SPEC)) 

(STATE-2  (UNFOLD  BOTH  CONSTRAINTS) 

(APPLY  TRANSFORMATION  .  UNFOLD-CONSTRAINT)) 

(SrATE-3  (SIMPLIFY;  REMOVE  REDUNDANT  UNFOLDED  CONSTRAINT  CHECKS) 
(MANUAL  EFFORT)) 

(STATE-4  (MAKE  BACKTRACKING  EXPLICIT  SO  THAT  IT  CAN  BE  MINIMIZED) 

(APPLY  IHANSFOHMAI  ION  .  UNFOLU-CDNSEQUENT 1 AL-BACKTRACKING)  ) 

(STATE-4-1  (CONVERT  ITERATION  TO  RECURSION) 

(JITTER  TRANSFOMATION  .  MAKE-SET-I TERATIDN-RECURSI VE) ) 

(STATE-4-2  (ACHIEVE  A  NECESSARY  PROPERTY  OF  A  TRANSFORMATION) 
(ACHIEVE  THE  FOLLOUING  PROPERTY: 

CONSEQUENT I AL -NON-DE  TERM I N I SM-FREE 
REMOVE  QUEEN  FROM  QUEEN-SET))) 

(STATE-4-2-1  (MARK  "REMOVE''  AS  INCIDENTAL  NON-DETERMINISM) 
(APPLY  TRANSFORMATION  . 

MARK- 1 NC I DENT AL-NON-DE TERM I N I SM ) ) 

(STATE-4-2-2 

NIL 

((CONSEQUENTIAL-NON-DETERMINISM-FREE  (REMOVE*  QUEEN  FROM 

QUEEN-SET)) 

PROVED  BY  NO-CONSEQUENTIAL-NON-DETERMINISM)) 

(STATE-4-3 

(ACHIEVE  A  NECESSARY  PROPERTY  OF  A  TRANSFORMATION) 

( (CONSEQUENTIAL-NON-DETERMINISM-FREE 
(LOCAL  .  .  .  ) 

PROVED  BY  NO-CONSEQUENT I AL-NON-OETERMINISM)) 

(STATE-4-4  (ACHIEVE  A  NECESSARY  PROPERTY  OF  A  TRANSFORMATION) 

( (CONSEQUENT  I AL-NON-DETERM I N I SM-FREE ) 

PROVED  BY  NO-CONSEQUENTIAL-NON-DETERMINISM)) 


(5TATE-5  (ASSIMILATE  CONSTRAINT  INTO  GENERATOR) 

(APPLY  TRANSFORMATION  .  ASSIMILATION-TEST-IN-THEREIS-LOOP) ) 

(STATE-5-1  (MERGE  THE  LOCALS) 

(JITTER  TRANSFORMATION  .  MERGE-LOCALS)) 

(STATE-5-1-1  (EXTRACT  LOCAL  FROM  FDR  LOOP) 

(JITTER  TRANSFORMATION  . 

EXTRACT-LOCAL-FROM-FOR-LDOP) ) 

(STATE-5-3  (MOVE  CONSTRAINT  TEST  AHEAD  OF  ASSERTION) 

(JITTER  TRANSFORMATION  .  MOVE-CDNSTRAINT-UPHILL) ) 

(STATE-5-5  (SIMPLIFY:  SUPPRESS  NULL  ELSE  CLAUSE) 

(Jill  EH  IHANSFOHMAIIDN  .  ELSE-SUPPRESSIDN) ) 

(STATE-G  (ASSIMILATE  REMAINING  CONSTRAINT  INTO  LOOP  GENERATOR) 

(APPLY  TRANSFORMATION  .  ASSIMILATE-TEST-IN-THEREIS-LDDP) ) 

(STATE-G-1  (MOVE  REMAINING  CONSTRAINT  AHEAD  OF  ASSERTION) 

(JITTER  TRANSFORMATION  .  MOVE-CONSTRAINT-UPHILL)) 

(STATE-G-3  (SIMPLIFY:  SUPPRESS  NULL  ELSE  CLAUSE) 

(JITTER  TRANSFORMATION  .  ELSE-SUPPRESSION) ) 

(STATE-7  (SIMPLIFY:  REMOVE  EMBEDDED  APAND  IN  LOOP  GENERATOR) 

(APPLY  TRANSFORMATION  .  SIMPLIFY-APAND) ) 

(STATE-8  (MAINTAIN  ACCEPTABLE  BOARD  POSITIONS  INCREMENTALLY) 

(APPLY  TRANSFORMATION  .  CALCULATE-PREDICATE-INCREMENTALLY) ) 

(STATE-S  (SIMPLIFY:  REMOVE  REDUNDANT  LOOP  FROM  MAINTENANCE  ACTIONS) 
(MANUAL  EFFORT)) 

(STATE-10  (PICK  <ROU/!/  COLUMN^>  AS  REPRESENTATION  OF  BOARD  POSITION. 

RECOGNIZE  THAT  COMPONENTS  ARE  ORTHOGONAL  AND  CAN  BE 
INDEPENDENTLY  SELECTED.  FURTHERMORE.  RECOGNIZE  THAT 
ROU  AND  COLUMN  DETERMINE  NE-DIAGONAL  AND  SE-DIAGDNAL. 
FINALLY.  RECOGNIZE  THAT  POSSIBLE  BOARD-POSITIONS  CAN  BE 
GENERATED  FROM  THE  INTERSECTION  OF  THE  REMAINING  ROUS, 
COLUMNS.  AND  DIAGONALS.  AND  THAT  INCREMENTAL  UPDATE 
OF  POSSIBLE-BOARD-POSITIONS  MERELY  INVOLVES  REMOVING 
THE  CHOSEN  ROU.  COLUMN.  AND  TUO  DIAGONALS  BECAUSE 
THE  MAPPING  IS  ONE-TO-ONE  IN  BOTH  DIRECTIONS.) 

(MANUAL  EFFORT)) 
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This  appendix  contains  pairs  of  program  displays  In  which  the  changes  from  one  state 
Into  another  are  highlighted  In  boldface  type.  The  deleted  and/or  modified  text  Is 
highlighted  to  show  the  changes  out  of  a  state,  while  the  additions  and  modifications  are 
highlighted  to  show  the  changes  Into  the  next  state.  These  pairs  of  program  displays  are 
placed  on  facing  pages  for  ease  of  comparison.  They  were  produced  automatically  as 
part  of  the  documentation  of  the  development  [9]. 


TRANSFORMATIONAL  IMPLEMENTATION: 


CHANGES  OUT  OF  STATE-1 

ILAMBDA  (QUEEN-SET) 

(LOCAL  (BOARD-POSITION) 

(FOR  QUEEN  IN-SET  QUEEN-SET  DO 

(DETERMINE  BOARD-POSITION  FROM 

(CHESS-BOARD  BOARD-POSITION)) 
(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION) 


AN  EXAMPLE 


21 


CHANGES  INTO  SJATE-2 


(UMBDA  (QUEEN-SET) 

(LOCAL  (BOARD-POSITION) 

(FOR  QUEEN  IN-SET  QUEEN-SET  DO 
(DETERMINE  BOARD-POSITION  FROM 

(CHESS-BOARD  BOARD-POSITION)) 

iLOCAL  iBOARD-POSmONHIE  BOAND~POSmON01  QUEEN02  QUEEN01 
PIECE02  PIECEHII) 

.  (ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (PIECE-ON-BOABD  PIECE02  BOARD-POSITION) 

THEN 

(CONSTRAINT-VIOLATION 

TWO-PIECES-CAN*T-OCCUPY-SAME-SQUARE) 

ELSE  NIL 

(IF  (PIECE-ON-BOARD  PIECE01  BOARD-POSITION) 

THEN 

(CONSTRAINT-VIOLATION 

TWO-PIECES-CAN’T-OCCUPY-SAME-SQUARE) 

ELSE  NIL 

(IF  (AND  (PIECE-ON-BOARD  QUEEN02  BOARD-POSITIONIFE) 
(QUEEN-CAPTURE  BOARD-POSITION 
BOARD-POSITION02) ) 

THEN 

(CONSTRAINT-VIOLATION 

QUEEN-CAN’T-CAPTURE-ANOTHER-QUEEN) 

ELSE  NIL 

(IF  (AND  (PIECE-ON-BOARD  QUEEN01  BOARD-POSITION01 ) 
(QUEEN-CAPTURE  BOARD-POSITIONS  1 
BOARD-POSITION)) 

THEN 

(CONSTRAINT-VIOLATION 

QUEEN-CAN'T-CAPTURE-ANOTHER-QUEEN) 

ELSE  NIL 
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CHANGES  OUT  OF  STATE-2 


ILAMBOA  (QUEEN-SET) 

(LOCAL  (BOARD-POSITION) 

(FOR  QUEEN  IN-SET  QUEEN-SET  DO 
(DETERMINE  BOARD-POSITION  FROM 

(CHESS-BOARD  BOARD-POSITION)) 

(LOCAL  iBOARO-POSITION«2  BOARD-POSITION*  1  QUEEN*2  QUEEN*  1 
PIECE*2  PIECE*  1) 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION) 

THEN 

(CONSTRAINT-ViaATION 

TWO-PIECES-CAhTT-OCCUPY-SAME-SQUARE ) 

ELSE  NIL) 

tIF  iPIECE-ON-BOARD  PIECE01  BOARD-POSITION) 

THEN 

iCONSTRAINT-l^lOLATION 

TWO-PIECES-CAN‘T-OCCUPY-SAME-SQUARE) 

ELSE  NIL) 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSITION*2) 

(QUEEN-CAPTURE  BOARD-POSITION 
BOARD-POSITION*2)) 

THEN 

(CONS'^RAINT-VIOLATION 

QUEEN-CAN’T-CAPTURE-ANOTHER-QUEEN) 

ELSE  NIL) 

(IF  iAND  iPIECE-ON-BOARD  QUEEN01  BOARD-POSITION01) 
(QUEEN-CAPTURE  BOARD-POSITION01 
BOARD-POSITION)) 

THEN 

(CONSTRAINT-VIOLATION 

QUEEN-CAN^T-CAPTURE-ANOTHER-QUEEN) 

ELSE  NIL 


AN  EXAMPLE 


23 


CHANGES  INTO  STATES 


ILAMBDA  (QUEEN-SET) 

(LOCAL  (BOARD-POSITION) 

(FOR  QUEEN  IN-SET  QUEEN-SET  DO 
(DETERMINE  BOARD-POSITION  FROM 

(CHESS-BOARD  BOARD-POSITION)) 

(LXAL  (BOARD-POSITION(i2  BOARD-POSITION*  1  QUEEN«2  QUEEN*  1 
PIECE*2  PIECE*  1) 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION) 

THEN 

(CONSTRAINT-ViaATION 

TWO-PIECES-CAN’T-OCCUPY-SAME-SQUARE) 

ELSE  NIL) 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSITION*2) 
(QUEEN-CAPTURE  BOARD-POSITION 
BOARO-POSITION*2)) 

THEN 

(CONSTRAINT-VIOLATION 

QUEEN-CAN’T-CAPTURE-ANOTHER-QUEEN) 

ELSE  NIU 


TRANSFORMATIONAL  IMPLEMENTATION! 


CHANGES  OUT  OF  STATES 

(LAMBDA  (QUEEN-SET) 

(LOCAL  tBOAHD-POSmON) 

iFOH  QUEEN  IN-SET  QUEEN-SET  DO 

(DETERMINE  BOARD-POSITION  FROM 

(CHESS-BOARD  BOARD-POSITION)) 

(LOCAL  (B0ARD-P0SITI0N«2  BOARD-POSITION*  1  QUEEN*2  QUEEN*  1 
PIECE*2  PIECE*  1). 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION) 

THEN 

(CONSTRAINT-VIOLATION 

TWO-PIECES-CAN’T-OCCUPY-SAME-SQUARE) 

ELSE  NIL) 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSITION*2) 
(QUEEN-CAPTURE  BOARD-POSITION 
BOARD-POSITION*2)) 

THEN 

(CONSTRAINT-VIOLATION 

QUEEN-CAN’T-CAPTURE-ANOTHER-QUEEN) 

ELSE  N1U 


i 
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CHANGES  INTO  SJATE~4~1 


ILAMBOA  (QUEEN-SETi 

(LXAL  iQUEEN  BOARD-POSITION) 

tTERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(RETURN))) 

(REMOVE  QUEEN  FROM  QUEEN-SET) 

«DETERMINE  BOARD-POSITION  FROM  (CHESS-BOARD  BOARD-POSITION)) 
(LOCAL  (B0ARD-P0SITI0N«2  BOARD-POSITION#  1  0UEEN«2  QUEEN#  1 
PIECE#2  PIECE#  1) 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (PIECE-ON-BOARD  PIECE#2  BOARD-POSITION) 

THEN 

(CONSTRAINT-VIOLATION 

TWO-PIECES-CANT-OCCUPY-SAME-SQUARE) 

ELSE  NIL) 

(IF  (AND  (PIECE-ON-BOARD  QUEEN#2  BOARD-POSITION#2) 

(QUEEN-CAPTURE  BOARD-POSITION  BOARD-POSITION#2)) 

THEN 

(CONSTPAINT-ViaATION 

QUEEN-CAN’T-CAPTURE-ANOTHER-QUEEN) 

ELSE  NIL)) 

(RECURSIVE-CAUt  (QUEENS  QUEEN-SET) 


t 


transformational  IMRLEMENTATIONi 


CHANGES  OUT  OF  STATE-A-I 


ILAMBOA  IQUEEN-SET) 

(LOCAL  (QUEEN  BOARD-POSITION) 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(RETURN))) 

{REMOVE  QUEEN  FROM  QUEEN-SET) 

(DETERMINE  BOARD-POSITION  FROM  (CHESS-BOARD  BOARD-POSITION)) 
(LOCAL  (BOARD-POSITION«2  BOARD-POSITION*  1  QUEEN«2  QUEENsl 
PIECE*2  PIECE*  1) 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION) 

THEN 

(CONSTRAINT-VIOLATION 

TWO-PIECES-CAN’T-OCCUPY-SAME-SQUARE) 

ELSE  NIL) 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSITION* 2) 

(QUEEN-CAPTURE  BOARD-POSITION  BOARD-POSITION*2)) 

THEN 

(CONSTRAINT-VIOLATION 

QUEEN-CAN*T-CAPTURE-ANOTHER-QUEEN) 

ELSE  NIL)) 

(RECURSIVE-CALL:  (QUEENS  QUEEN-SET) 


AN  EXAMPLE 
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CHANGES  INTO  STATE-4-2-1 


tLAMBDA  (QUEEN-SET) 

(LOCAL  (QUEEN  BOARD-POSITION) 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(RETURN))) 

tHEMOVE*  QUEEN  FROM  QUEEN-SET) 

(DETERMINE  BOARD-POSITION  FROM  (CHESS-BOARD  BOARD-POSITION)) 
(LOCAL  (B0AR0-P0StTI0N«2  BOARD-POSITION*  1  QUEEN*2  QUEEN*  1 
PIECE*2  PIECE*  1) 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION) 

THEN 

(CONSTRAINT-VIOLATION 

TWO-PIECES-CANTT-OCCUPY-SAME-SQUARE) 

ELSE  NIL) 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSITION*2) 

(QUEEN-CAPTURE  BOARD-POSITION  BOARD-POSITION*2)> 

THEN 

(CONSTRAINT-VIOLATION 

0UEEN-CAN*T-CAPTURE-AN0THER-QUEEN) 

ELSE  NIL)) 

(RECURSIVE-CALL:  (QUEENS  QUEEN-SET) 


TRANSFORMATIONAL  IMPLEMENTATION! 


CHANGES  our  OF  STATE-4-2-1 


ILAMBDA  (QUEEN-SET) 

(LOCAL  (QUEEN  BOARD-POSITION) 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(NETUNNi 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 

tDETERMINE  BOARD-POSITION  FROM  (CHESS-BOARD  BOARD-POSITION)) 
(LOCAL  (BOARO-POSITION«2  BOARD-POSITION*  1  QUEEN*2  QUEEN*  1 
PIECE*2  PIECE*  1) 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (PIECE-ON-BOARD  P1ECE*2  BOARD-POSITION) 

THEN 

(CONSTRAINT-VIOLATION 

TWO-PIECES-CAN’T-OCCUPY-SAME-SQUARE) 

ELSE 

NIL) 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSITION*2) 

(QUEEN-CAPTURE  BOARD-POSITION  BOARD-POSITION*2) ) 

THEN 

(CONSTRAINT-VIOLATION 

QUEEN-CAN'T-CAPTURE-ANOTHER-QUEEN^ 

ELSE 

NIL)) 

(RECURSIVE-CALL:  (QUEENS  QUEEN-SET) 


AN  EXAMPLE 


29 


CHANGES  INTO  STATE~4 


ILAMBDA  (QUEEN-SET) 

(LOCAL  (QUEEN  BOARD-POSITION) 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(EX/T  SUCCESSFUL 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 
iFON  ALL  (CHESS-BOARD  BOARD-POSITION) 

THEREIS 

(LOCAL  (BOARD-POSITION«2  BOARD-POSITION*  1  QUEEN*2  QUEEN*  1 
PIECE*2  PIECE*  1) 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION) ) 

(IF  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION) 

THEN 

iUNDO-ACTIONS:  tDENY  tPIECE-ON-BOAND  QUEEN 

BOARD-POSmON)^y 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) 

ELSE 

NIL) 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSITION*2) 
(QUEEN-CAPTURE  BOARD-POSITION 
BOARD-POSITION*2)) 

THEN 

(UNDO-ACTIONSt  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) 

ELSE 

NIL)) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET] 

THEN 

(LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) ) 

THEN 

(EXIT  SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS:  (ADD  QUEEN  TO  QUEEN-SET)) 

(EXIT  UNSUCCESSFUL 


TRANSFORMATIONAL  IMPLEMENTATIONt 


CHANGES  OUT  OF  STATE-4 


(LAMBDA  (QUEEN-SET) 

(LOCAL  (QUEEN  BOARD-POSITION) 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(EXIT  SUCCESSFUL))) 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 

(FOR  all  (CHESS-BOARD  BOARD-POSITION) 

THEREIS 

(LOCAL  (BOARD-POSITION*2  BOARD-POSITION*  1  QUEEN*2  QUEEN*  1 
PIECE*2  PIECE*  1) 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION) 

THEN 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) 

ELSE  NIL) 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSITION*2) 
(QUEEN-CAPTURE  BOARD-POSITION 
BOARD-POSITlON*2)) 

THEN 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) 

ELSE  NIL)) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET))) 

THEN 

(LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT  SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS:  (ADD  QUEEN  TO  QUEEN-SET» 

(EXIT  UNSUCCESSFUU 


AN  EXAMPLE 
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CHANGES  INTO  STATE~8~1-1 


(LAMBDA  (QUEEN-SET) 

(LOCAL  (QUEEN  BOARD-POSITION) 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(EXIT  SUCCESSFUL))) 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 

(LOCAL  (BOARO-POSITION«2  BOARD-POSITION*  1  QUEEN*2  QUEEN*  1 
PIECE*2  PIECE*  1) 

(FOR  ALL  (CHESS-BOARD  BOARD-POSITION) 

THEREIS 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION) 

THEN 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) 

ELSE  NIL) 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSITION*2) 
(QUEEN-CAPTURE  BOARD-POSITION 
BOARD-POSITION*2>) 

THEN 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) 

ELSE  NIL) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET)) 
> 

THEN 

(LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT  SUCCESSFW.) 

ELSE 

(UNDO-ACTIONS:  (ADO  QUEEN  TO  QUEEN-SET)) 

(EXIT  UNSUCCESSFUU 
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TRANSFORMATIONAL  IMPLEMENTATION: 


CHANGES  OUT  OF  STATE-S-I-I 


ILAMBOA  (QUEEN-SET) 

(LOCAL  iCiUEEN  BOARD-POSITION) 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(EXIT  SXCESSFUL))) 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 

iLOCAL  (BOARD-POSITION02  BOARD-POSITIONS  1  QUEENS2  QUEENS  1 
PIECES2  PIECES!) 

(FOR  ALL  (CHESS-BOARD  BOARD-POSITION) 

THEREIS 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (PIECE-ON-BOARD  PIECE«2  BOARD-POSITION) 

THEN 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) 

ELSE  NIL) 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSITION«2) 

(QUEEN-CAPTURE  BOARD-POSITION 
B0ARD-P0SITI0N«2)) 

THEN 

(UNOO-ACTIONS:  (DENY  (PlECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) 

ELSE  NIL) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET)) 

) 

THEN 

(LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNOO-ACTIONS;  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT  SUCCESSFUL) 

ELSE 

(UNOO-ACTIONS:  (ADO  QUEEN  TO  QUEEN-SET)) 

(EXIT  UNSUCCESSFIAJ 


AN  EXAMPLE 
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CHANGES  INTO  STATE~S-1 


ILAMBOA  cQUEEN-SET> 

(LOCAL  tQUEEN  BOARD-POSITION  BOARD-POSIT  I  ON  02  BOARD-POSITIOfl01  QUE 
QUEEN  01  PIECE02  PIECE01} 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(EXIT  SUCCESSFUL))) 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 

(FOR  ALL  (CHESS-BOARD  BOARD-POSITION) 

THEREIS 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (PIECE-ON-BOARD  PIECEa2  BOARD-POSITION) 

THEN 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION) ) ) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) 

ELSE  NIL) 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSITION»2) 

(QUEEN-CAPTURE  BOARD-POSITION  BOARD-POSITION*2)) 

THEN 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) 

ELSE  NIL) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET))) 

THEN 

(LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT  SUCCESSFUL) 

ELSE 

(UNOO-ACTIONS:  (ADD  QUEEN  TO  QUEEN-SET)) 

(EXIT  UNSUCCESSFUL) 
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TRANSFORMATIONAL  IMPLEMENTATIONt 


CHANGES  OUT  OF  STATE-5~1 


ILAMBDA  (QUEEN-SET) 

CLOCAL  (QUEEN  BOARD-POSITION  B0ARD-P0SITI0N32  BOARD-POSITlONsl  QUEEN«2 
QUEEN*  1  PIECE*2  PIECE*  1) 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(EXIT  SUCCESSFUL))) 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 

(FOR  ALL  (CHESS-BOARD  BOARD-POSITION) 

THEREIS 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION) 

THEN 

iUNDO-ACTIONSi  (DENY  tPIECE-ON~BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) 

ELSE 

NIL) 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSITION*2) 

(QUEEN-CAPTURE  BOARD-POSITION  BOARD-POSITION*2) ) 

THEN 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) 

ELSE  ML) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET)  )> 

then 

(LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT  SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS:  (ADD  QUEEN  TO  QUEEN-SET)) 

(EXIT  UNSUCCESSFUL) 


AN  EXAMPLE 
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CHANGES  mo  STATE-5-3 


ILAMBDA  (QUEEN-SET) 

(LOCAL  (QUEEN  BOARD-POSITION  B0ARD-P0SITI0N*2  BOARD-POSITION*  1  0UEEN*2 
QUEEN*  1  PIECE*2  PIECE*  1) 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(EXIT  SUCCESSFUL))) 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 

(FOR  ALL  (CHESS-BOARD  BOARD-POSITION) 

THEREIS 

(IF  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION) 

THEN 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) 

ELSE  NIL) 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION) ) 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSITION*2) 

(QUEEN-CAPTURE  BOARD-POSITION  BOARD-POSITION*2)) 

THEN 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) 

ELSE  NIL) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL;  (QUEENS  QUEEN-SET))) 

THEN 

(LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT  SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS:  (ADD  QUEEN  TO  QUEEN-SET)) 

(EXIT  UNSUCCESSFUU 
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TRANSFORMATIONAL  IMPLEMENTATION: 


CHANGES  OUT  OF  STATE-S-S 


tLAMBDA  (QUEEN-SET) 

(LOCAL  (QUEEN  BOARD-POSITION  B0ARD-P0SITI0Na2  B0AR0-P0SITI0N(i1  QUEENa2 
QUEENal  PIECE«2  PIECE*  1) 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(EXIT  SUCCESSFUL))) 

(RE.’OVE*  QUEEN  FROM  QUEEN-SET) 

(FOR  ALL  (CHESS-BOARD  BOARD-POSITION) 

THEREIS 

(IF  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION) 

THEN 

(LOOP-RETURN  FORCE-ANOTHER-CHOICEi 

ELSE 

NIL 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  B0ARD-P0SITI0N*2) 

(QUEEN-CAPTURE  BOARD-POSITION  B0ARD-P0SITI0N*2>) 

THEN 

(UNDO-ACTIONS:  (DENY  iPlECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) 

ELSE  NIL) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET))) 

THEN 

(LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT  SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS:  (ADD  QUEEN  TO  QUEEN-SET)) 

(EXIT  UNSUCCESSFUU 


AN  EXAMPLE 
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CHANGES  INTO  STATE-5-S 


tLAMBDA  (QUEEN-SET) 

(LOCAL  (QUEEN  BOARD-POSITION  BOARD-POSITION*2  BOARD-POSITION*  1  QUEEN*2 
QUEEN*  1  PIECE*2  PIECE*  1) 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(EXIT  SUCCESSFUL))) 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 

(FOR  ALL  (CHESS-BOARD  BOARD-POSITION) 

THEREIS 

(IF  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION) 

THEN 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) ) 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSITION*2) 

(QUEEN-CAPTURE  BOARD-POSITION  BOARD-POSITION*2) ) 

THEN 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) 

ELSE  NIL) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET))) 

THEN 

(LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT  SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS:  (ADD  QUEEN  TO  QUEEN-SET)) 

(EXIT  UNSUCCESSFUU 


TRANSFORMATIONAL  IMPLEMENTATION! 


CHANGES  OUT  OF  STATE-S-S 


lUMBDA  (QUEEN-SET) 

(LOCAL  (QUEEN  BOARD-POSITION  B0ARD-P0SITI0Nii2  BOARO-POSITIONul  QUEEN«2 
QUEEN* i  PIECE*2  PIECE*  1) 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(EXIT  SUCCESSFUL))) 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 

(FOR  ALL  (CHESS-BOARD  BOARD-POSITION) 

THEREIS 

(/f  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION) 

THEN 

tLOOP-HETUHN  FORCE-ANOTHER-CHOICEi ) 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSITION*2) 

(QUEEN-CAPTURE  BOARD-POSITION  BOARD-POSITION*2)) 

THEN 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) 

ELSE  NIL) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET))) 

THEN 

(LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT  SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS:  (ADD  QUEEN  TO  QUEEN-SET)) 

(EXIT  UNSUCCESSFUU 


AN  EXAMPLE 
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CHANGES  INTO  STATE-^S 


ILAMBOA  (QUCEN-SET) 

(LOCAL  (QUEEN  BOARD-POSITION  BOARO-POSITION«2  BOARO-POSITIONsl  QUEEN«2 
QUEENul  PIECE«2  PIECE*  1> 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(EXIT  SUCCESSFUL))) 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 

(FOR  ALL  lAPAND  (CHESS-BOARD  BOARD-POSITION) 

(NOT  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION) 

THEREIS 

(ASSERT  (PIECE -ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSITION*2) 

(QUEEN-CAPTURE  BOARD-POSITION  BOARD-POSITION*2) ) 

then 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) 

ELSE  NIL) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET))) 

THEN 

(LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT  SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS:  (AW)  QUEEN  TO  QUEEN-SET)) 

(EXIT  UNSUCCESSFUU 


TRANSFORMATIONAL  IMPLEMENTATION! 


CHANGES  OUT  OF  STATES 


ILAMBOA  (QUEEN-SET) 

(LOCAL  (QUEEN  BOARD-POSITION  B0ARD-P0SITI0N«2  BOARD-POSITION*  1  QUEEN*2 
QUEEN*  1  PIECE*2  PIECE*  1) 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(EXIT  SUCCESSFUL))) 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 

(FOR  ALL 

(APAND  (CHESS-BOARD  BOARD-POSITION) 

(NOT  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION))) 

THEREIS 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSITION*2) 

(QUEEN-CAPTURE  BOARD-POSITION  BOARD-POSITION*2)) 

THEN 

tUNDO-ACTIONSt  iDENY  tPIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RHURN  FORCE-ANOTHER-CHOICE) 

ELSE 

NIL) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET))) 

THEN 

(LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT  SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS:  (ADD  QUEEN  TO  QUEEN-SET)) 

(EXIT  UNSUCCESSFUU 


AN  EXAMPLE 
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CHANGES  INTO  STATE-S-1 


ILAMBOA  (QUEEN-SET) 

(LOCAL  (QUEEN  BOARD-POSITION  BOARD-POSITION*2  BOARD-POSITION*  1  QUEEN*2 
QUEEN*  1  PIECE*2  PIECE*  1) 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(EXIT  SUCCESSFUL))) 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 

(FOR  ALL 

(APAND  (CHESS-BOARD  BOARD-POSITION) 

(NOT  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION))) 

THEREIS 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSITION*2) 

(QUEEN-CAPTURE  BOARD-POSITION  BOARD-POSITION*2)) 

THEN 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) 

ELSE  NIL) 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET))) 

THEN 

(LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT  SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS:  (ADO  QUEEN  TO  QUEEN-SET)) 

(EXIT  UNSUCCESSFUL) 
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TRANSFORMATIONAL  IMRLEMENTATIONt 


CHANGES  OUT  OF  STATE-6-1 


ILAMBDA  (QUEEN-SET) 

ILOCAL  (QUEEN  BOARD-POSITION  BOARO-POSITIONo2  BOARD-POSITIONaI  QUEEN«2 
QUEEN*  1  PIECE*2  PtECE*l) 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(EXIT  SUCCESSFUL))) 

(REMOVE*  QUEEN  FROM  QLSEN-SET) 

(FOR  ALL 

(APANO  (CHESS-BOARD  BOARD-POSITION) 

(NOT  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION))) 

THEREIS 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSlTION*2) 

(QUEEN-CAPTURE  BOARD-POSITION  BOARD-POSITION*2)) 

THEN 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) 

ELSE 

NIL 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (SUCCESSFUL  iRECUPSIVE-CALL:  (QUEENS  QUEEN-SET))) 

THEN 

(LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT  SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS:  (ADD  QUEEN  TO  QUEEN-SET)) 

(EXIT  UNSUCCESSFUU 


AN  EXAMPLE 
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CHANGES  INTO  STATE~6~3 


ILAMBDA  (QUEEN-SET) 

(LOCAL  (QUEEN  BOARD-POSITION  BOARD-POSlTION«2  BOARD-POSITION*  1  QUEEN*2 
QUEEN*  1  PIECE*2  PIECE*  1) 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(EXIT  SUCCESSFUL))) 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 

(FOR  ALL 

(APAND  (CHESS-BOARD  BOARD-POSITION) 

(NOT  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION))) 

THEREIS 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSITION*2) 

(QUEEN-CAPTURE  BOARD-POSITION  BOARD-POSITION*2) ) 

THEN 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE)) 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET))) 

THEN 

(LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT  SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS;  (ADD  QUEEN  TO  QUEEN-SET)) 

(EXIT  UNSUCCESSFUL! 
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TRAN8FOHMATIONAL  IMPLEMENTATION* 


CHANGES  OUT  OF  STATE-6‘3 


ILAMBDA  (QUEEN-SETi 

ILOCAL  iQUEEN  BOARD-POSITION  B0ARD-P0SITI0N*2  BOARD-POSITION«1  QUEEN«2 
QUEEN*  1  PIECE*2  PIECE*  1) 

<TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(EXIT  SUCCESSFUL))) 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 

(FOR  ALL 

(APANO  (CHESS-BOARD  BOARD-POSITION) 

(NOT  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION))) 

THEREIS 

(IF  (AND  (PIECE-ON-BOARD  QUEEN*2  BOARD-POSITION*2) 

(QUEEN-CAPTURE  BOARD-POSITION  BOARD-POSITION*2)) 

THEN 

tLOOP-HETUHN  FORCE-ANOTHER-CHOICE) ) 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET))) 

THEN 

(LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) ) 

THEN 

(EXIT  SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS:  (ADD  QUEEN  TO  QUEEN-SET)) 

(EXIT  UNSUCCESSFUU 


d 


AN  EXAMPLE 
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CHANGES  INTO  STATES 


ILAMBDA  (QUEE/j-SET) 

(LOCAL  (QUEEN  BOARD-POSITION  BOARD-POSITION»2  BOARD-POSITIONaI  QUEENa2 
QUEENal  PIECE«2  PIECE*  1) 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(EXIT  SUCCESSFUL))) 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 

(FOR  ALL 

tAPAND  (APAND  (CHESS-BOARD  BOARD-POSITION) 

(NOT  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION) ) 

) 

(NOT  (AND  (PIECE-ON-BOARD  0UEEN«2  BOARD-POSITIONa2) 
(QUEEN-CAPTURE  BOARD-POSITION 
BOARO-POSITION»2l 

THEREIS 

(ASSERT  (PIECE -ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET))) 

THEN 

(LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION) ) ) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT  SUCCESSFUL) 

ELSE 

(UNOO-ACTIONS:  (ADD  QUEEN  TO  QUEEN-SET)  > 

(EXIT  UNSUCCESSFUU 


TRANSFORMATIONAL  IMPLEMENTATION: 


CHANGES  OUT  OF  STATES 


ILAMBOA  (QUEEN-SET) 

(LOCAL  (QUEEN  BOARD-POSITION  B0AR0-P0SITI0N«2  BOARD-POSITION#  1  QUEEN«2 
QUEEN#  1  PIECE#2  PIECE#  1> 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN 

(EXIT  SUCCESSFUL))) 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 

(FOR  ALL 

lAPAND  lAPAND  (CHESS-BOARD  BOARD-POSITION) 

(NOT  (PIECE-ON-BOARD  PIECE#2  BOARD-POSITION) 

(NOT  (AND  (PIECE-ON-BOARD  QUEEN#2  BOARD-POS1TION#2) 
(Ql£EN-CAPTURE  BOARD-POSITION 
BOARD-POSITION#2l 

THEREIS 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET))) 

THEN 

(LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) ) 

THEN 

(EXIT  SUCCESSFUL) 

ELf" 

(UNDO-ACTIONS:  (ADD  QUEEN  TO  QUEEN-SET)) 

(EXIT  UNSUCCESSFUU 


AN  EXAMPLE 
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CHANGES  INTO  STATE-? 


ILAMBDA  (QUEEN-SET) 

(LCKAL  (QUEEN  BOARD-POSITION  BOARD-POSITIONa2  BOARD-POSITIONaI  0UEENa2 
QUEEN*  1  PIECE«2  PIECE*  1) 

(TERMINATION-TEST;  (IF  (EMPTY  QUEEN-SET) 

THEN 

(EXIT  SUCCESSFUL))) 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 

(FOR  ALL 

lAPAND  (CHESS-BOARD  BOARD-POSITION) 

(NOT  (PIECE-ON-BOARD  PIECE*2  BOARD-POSITION)) 

(NOT  (AND  (PIECE-ON-BOARD  0UEEN*2  BOARD-POSITlON*2) 
(QUEEN-CAPTURE  BOARD-POSITION 
BOARD-POSlTION*2) 

THEREIS 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET))) 

THEN 

(LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) ) 

THEN 

(EXIT  SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS:  (ADD  QUEEN  TO  QUEEN-SET)) 

(EXIT  UNSUCCESSFUU 
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TRANSFORMATIONAL  IMPLEMENTATION: 


CHANGES  OUT  OF  ST  ATE-7 
ILAMBOA  (QUEEN-SET) 

lUXAL  iQUEEN  BOARD-POSITION  B0ARD-P0SITI0N*2  BOARD-POSITION#  1  QUEEN#2 
QUEEN#  1  PIECE#2  PIECE#  1) 

ITERMINATION-TEST:  lIF  lEMPTY  QUEEN-SET) 

THEN 

lEXIT  SUCCESSFUL))) 

IREMOVE*  QUEEN  FROM  QUEEN-SET) 

(FOR  ALL 

lAPAND  (CHESS-BOARD  BOARD-POSITION) 

(NOT  (PIECE-ON-BOARD  PIECE^Z  BOARD-POSITION)) 

(NOT  (AND  (PIECE-ON-BOARD  QUEENA2  BOARD-POSmON02y 
(QUEEN-CAPTURE  BOARD-POSITION 
BOARD-POSmON02i 

THEREIS 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET))) 

THEN 

(LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT  SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS:  (ADD  QUEEN  TO  QUEEN-SET)) 

(EXIT  UNSUCCESSFUL) 


AN  EXAMPLE 
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CHANGES  INTO  STATE-S 


(LAMBDA 

t QUEEN-SET  POSSIBLE-BOARD-POSITIONS) 

«LCX:AL  (QUEEN  BOARD-POSITION  BOARD-POSmON«2  BOARD-POSITION*  1  QUEEN*2  QUEEN*  1 
PIECE*2  PIECE*!) 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET)  THEN  (EXIT  SUCCESSFUL))) 

(REMOVE*  QUEFN  FROM  QUEEN-SET) 

(FOfl  (BO^KO-POS/T/OW)  IN-SET  POSSIBLE-BOAPD-POSITIONS  THEREIS 
iMAINTENANCE-ACTIONS:  .FOR  ALL 

tAPAND  (CHESS-BOARD  BOARD-POSITION) 

(NOT  (AND  (PIECE-ON-BOARD  QUEENIII3  BOARD-POSITION03) 

(QUEEN-CAPTURE  BOARD-POSITION  BOARD-POSITION03))) 
(NOT  (PIECE-ON-BOARD  PIECE^Z  BOARD-POSITION))) 

LBIND  (B0ARD-P0SITI0Nil3  QU££A/#3) 

DO  (DELETE  BOARD-POSITION  FROM  POSSIBLE-BOARD-POSITIONS)) 

(FOR  ALL 

lAPAND  (CHESS-BOARD  BOARD-POSITIONUfS) 

(NOT  (PIECE-ON-BOARD  PIECE03  BOARD-POSITIONUfS)) 
(QUEEN-CAPTURE  BOARD-POSITIONUfS  BOARD-POSITION) 

(NOT  (AND  (PIECE-ON-BOARD  QUEENUfZ  BOARD-POSmON02) 

(QUEEN-CAPTURE  BOARD-POSITION  BOARD-POSITION02) 
LBIND  (BOARD-POSlTIONKfS  P/£C£#3) 

DO  (DELETE  B0ARD-P0SITI0Nif3  FROM  POSSIBLE-BOARD-POSITIONS))) 

(ASSERT  (PIECE-ON-BOARO  QUEEN  BOARD-POSITION)) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET))) 

THEN  (LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE  ’ 

(UNDO-ACTIONS: 

(DENY  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

iMAINTENANCE-ACTIONS:  (FOR  ALL 

(APANO  (CHESS-BOARD  BOARD-POSITION) 

(NOT  (AND  (PIECE-ON-BOARD  QUEEN03  BOARD-POSITION03) 

(QUEEN-CAPTURE  BOARD-POSITION  BOARD-POSITION03))) 
(NOT  (PIECE-ON-BOARD  PIECE02  BOARD-POSITION))) 

LBIND  (BOARD-POSITION03  QUEENA3) 

DO  (ADD  BOARD-POSITION  TO  POSSIBLE-BOARD-POSITIONS)) 
iPOR  ALL 

lAPAND  (CHESS-BOARD  BOARD-POSITION03) 

(NOT  (PIECE-ON-BOARD  PIECE03  BOARD-POSITION03)) 
(QUEEN-CAPTURE  BOARD-POSITION03  BOARD-POSITION) 

(NOT  (AND  (PIECE-ON-BOARD  QUEEN02  BOARD-POSITION 02) 

(QUEEN-CAPTURE  BOARD-POSITION  BOARD-POSITION02) 
LBIND  (BOARD-POSITION03  PIECE03) 

DO  (ADD  BOARD-POSITION03  TO  POSSIBLE-BOARD-POSITIONS) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) ) 

THEN  (EXIT  SUCCESSFUL) 

ELSE  (UNTO-ACTIONS:  (ADO  QUEEN  TO  QUEEN-SET) ) 

(EXIT  unsuccessful 
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TRANSFORMATIONAL  IMPLEMENTATION: 


CHANGES  OUT  OF  STATES 

CLAMBDA  <0UEEN-SET  POSSIBLE-BOARD-POSITIONS) 

(LOCAL  (QUEEN  BOARD-POSITION  B0ARD-P0SITI0N«2  BOARD-POSITION#  1  QUEEN#2 
QUEEN*  1  PIECE*2  PIECE*  1) 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET)  THEN  (EXIT  SUCCESSFUL))) 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 

(FOR  (BOARD-POSITION)  IN-SET  POSSIBLE-BOARD-POSITIONS  THEREIS 
(MAINTENANCE-ACTIONS: 

(FOA  ALL  lAPAND  tCHESSSOARD  BOARD-POSITION) 

(NOT  (AND  (PIECE-ON-BOARD  QUEEN03 
BOARD-POSITION03) 
(QUEEN-CAPTURE  BOARD-POSITION 
BOARD-POSITION03) ) ) 

(NOT  (PIECE-ON-BOARD  PIECE02  BOARD-POSITION) 
LBIND  (BOARD-POSITION IF 3  QUEENIF3)  DO 
(DELETE  BOARD-POSITION  FROM  POSSIBLE-BOARD-POSITIONS 

(FOR  ALL  lAPAND  (CHESS-BOARD  B0ARD-P0SITI0N«3) 

(NOT  (PIECE-ON-BOARD  PIECE*3  B0ARD-P0SITI0N*3)) 

(QUEEN-CAPTURE  B0ARD-P0SITI0N*3  BOARD-POSITION) 

(NOT  (AND  (PIECE-ON-BOARD  QUEEN*2  B0ARD-P0SITI0N*2) 

(QUEEN-CAPTURE  BOARD-POSITION  B0ARD-P0SITI0N*2l 
LBIND  (B0ARD-P0SITI0N*3  PIECE*3) 

DO  (DELETE  B0ARD-P0SITI0N*3  FROM  POSSIBLE-BOARD-POSITIONS) 

(ASSERT  (PIECE-ON-BOARO  QUEEN  BOARD-POSITION)) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET))) 

THEN  (LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: 

(DENY  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(MAINTENANCE-ACTIONS: 

(FOR  ALL  (APAND  (CHESS-BOARD  BOARD-POSITION) 

(NOT  (AND  (PIECE-ON-BOARD  QUEEN03 
BOARD-POSITIONmS) 
(QUEEN-CAPTURE  BOARD-POSITION 
BOARD-POSITION03) ) ) 

(NOT  (PIECE-ON-BOARD  PIECE02 
BOARD-POSITION))) 

LBIND  (BOARD-POSITION IF 3  QUEENIF3)  DO 

(ADD  BOARD-POSITION  TO  POSSIBLE-BOARD-POSITIONS)) 

(FOR  ALL  (APAND  (CHESS-BOARD  B0ARD-P0SITI0N*3) 

(NOT  (PIECE-ON-BOARD  PIECE*3  B0ARD-P0SITI0N*3)) 

(QUEEN-CAPTURE  B0ARD-P0SITI0N*3  BOARD-POSITION) 

(NOT  (AND  (PIECE-ON-BOARD  QUEEN*2  B0ARD-P0SITI0N*2) 

(QUEEN-CAPTURE  BOARD-POSITION  BOARD-POSITION*2J 
LBIND  (B0ARD-P0SITI0N*3  PIECE*3) 

DO  (ADD  B0ARD-P0SITI0N*3  TO  POSSIBLE-BOARD-POSITIONS) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) ) 

THEN  (EXIT  SUCCESSFUL) 

ELSE  (UNDO-ACTIONS:  (ADO  QUEEN  TO  QUEEN-SET)) 

(EXIT  UNSUCCESSFUU 


J 


CHANGES  INTO  STATE-9 


CLAMBDA  <QUEEN-SET  POSSIBLE-BOARD-POSITIONS) 

•LOCAL  (QUEEN  BOARD-POSITION  BOARD-POSITION*2  BOARD-POSITION#  1  QUEEN#2 
QUEEN#  1  PtECE#2  PIECE#  1) 

•TERMINATION-TEST:  tW  jEMPTY  QUEEN-SET) 

THEN  <EXIT  SUCCESSFUL))) 

•REMOVE*  QUEEN  FROM  QUEEN-SET) 

•FOR  •BOARD-POSITION)  IN-SET  POSSIBLE-BOARD-POSITIONS 
THEREIS 

tMAlNTENANCE-ACTIONS: 

•FOR  ALL 

•APAND  (CHESS-BOARD  BOARD-POSITION#3) 

•NOT  (PIECE -ON-BOARD  PIECE#3  B0ARD-P0SITI0N#3)) 
•QUEEN-CAPTURE  BOARD-POSITION#3 
BOARD-POSITION) 

•NOT  (AND  (PIECE-ON-BOARD  0UEEN#2 

BOARD-POSITION#2) 
(QUEEN-CAPTURE  BOARD-POSITION 
BOARD-POSITION#2l 
LBIND  (BOARD-POSITION#3  PIECE#3) 

DO  (DELETE  B0ARD-P0SITI0N#3  FROM 
POSSIBLE-BOARD-POSITIONS) 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

•IF  (SXCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET))) 

THEN  (LOOP-RETLWN  CHOICE-ACCEPTED) 

ELSE 

•UNDO-ACTIONS: 

•DENY  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 
(MAINTENANCE-ACTIONS: 

•FOR  ALL 

•APAND  (CHESS-BOARD  B0ARD-P0SITI0N#3) 

•NOT  •PIECE-ON-BOARD  PIECE#3 

BOARD-POSITION#3)) 
(QLCEN-CAPTURE  B0ARD-P0SITI0N#3 
BOARD-POSITION) 

•NOT  (AND  (PIECE-ON-BOARD  QUEEN#2 
BOARD-POSITION#2) 
•QUEEN-CAPTURE  BOARD-POSITION 
BOARD-POSITION#2l 
LBIND  (B0ARD-P05ITI0N#3  PIECE#3) 

DO 

(ADO  BOARD-POSITION#3  TO 
POSSIBLE-BOARD-POSITIONS) 

•LOOP-RETURN  FORCE-ANOTHER-CHOICE) ) 

THEN  (EXIT  SUCCESSFUL) 

ELSE 

•UNDO-ACTIONS:  •ADD  QUEEN  TO  QUEEN-SETii 
•EXIT  UNSUCCESSFIAj 


TRANSFORMATIONAL  IMPLEMENTATION: 


CHANGES  OUT  OF  SJATE-9 


(LAMBDA 

( QUEEN -SET  POSSIBLE-BOAND-POSITIONS) 

(LOCAL 

(QUEEN  BOARD-POSITION  B0ARD-P0SITI0N»2  BOARD-POSITION*  1  QUEEN*2  QUEEN*  1 
PIECE*2  PIECE*  1> 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN  (EXIT  SUCCESSFUL))) 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 

tPON  iBOAND-POSmON)  IN-SET  POSSIBLE-BOAPD-POSITIONS 
TNEREIS 

iMAINTENANCE-ACTIONS:  (FOR  ALL 

lAPAND  (CHESS-BOARD  BOARD-POSITIONAS) 

(NOT  (PIECE-ON-BOARD  PIECEA3 

BOARD-POSmON03) ) 
(QUEEN-CAPTURE  BOARD-POSITION03 
BOARD-POSITION) 

(NOT  (AND  (PIECE-ON-BOARD  QUEEN02 
BOARD-POSmON02) 
(QUEEN-CAPTURE  BOARD-POSITION 
BOARD-POSITION02y 
LBIND  (BOARD-POSITION 03  PIECE03) 

DO 

(DELETE  BOARD-POSITION03  FROM 
POSSIBLE-BOARD-POSITIONS) ) ) 

(ASSERT  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN-SET) 

THEN  (LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE 

lUNDO-ACTIONS: 

(DENY  (PIECE-ON-BOARD  QUEEN  BOARD-POSITION)) 

(MAINTE.^ANCE-ACTlQNS:  (FOR  ALL 

lAPAND  (CHESS-BOARD  BOARD-POSITION03) 
(NOT  (PIECE-ON-BOARD  PIECE03 
BOARD-POSITION  03)) 
(QUEEN-CAPTURE  BOARD-POSITION03 
BOARD-POSITION) 

(NOT  (AND  (PIECE-ON-BOARD  QUEEN02 
BOARD-POSITION02) 
(QUEEN-CAPTURE  BOARD-POSITION 
BOARD-POSITION02) 

LBIND  (BOARD-POSITION03  PIECE03) 

DO 

(ADD  BOARD-POSITION03  TO 
POSSIBLE-BOARD-POSITIONS) 

(LOOP-RETURN  FORCE-ANOTHER-CHOICE) ) 

THEN  (EXIT  SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS:  (ADD  QUEEN  TO  QUEEN-SET)  > 

(EXIT  UNSUCCESSFUU 


CHANGES  INTO  STATE-10 


tUMBOA  tQUEEN-SET  REMAINING-ROWS  NEMAINING-COLUMNS 

NEMAINING-NE-DIAGONALSNEMAINING-SE-DIAGONALSy 
(LOCAL  (QUEEN  BOARD-POSITION  B0AR0-P05ITI0N«2  BOARD-POSITION*  1  QUEEN«2 
QUEEN*  1  PIECE*2  PIECE*  1) 

(TERMINATION-TEST:  (IF  (EMPTY  QUEEN-SET) 

THEN  (EXIT  SUCCESSFUL))) 

(REMOVE*  QUEEN  FROM  QUEEN-SET) 

(fOA  AOIV  IN-SET  REMAINING-ROWS  THEREIS 
tFOR  COLUMN  IN-SET  REMAINING-COLUMNS 
WHEN 

iPROGN  (DETERMINE*  NE-DIAGONAL  FROM 

(CORRESPONDING-NE-DAGONAL  ROW  COLUMN)) 
(DETERMINE*  SE-DIAGONAL  FROM 

(CORRESPONDING-SE-DIAGONAL  ROW  COLUMN) ) 

(APAND  (IN-SET?  NE-DIAGONAL  REMAINING-NE-DIAGONALS) 
(IN-SET?  SE-DIAGONAL  REMAINING-SE-DIAGONALS) 

II 

THEREIS 

(MAINTENANCE-ACTIONS:  (REMOVE*  ROW  FROM  REMAINING-ROWS) 
(REMOVE*  COLUMN  FROM 

REMAINING-COLUMNS) 

(REMOVE*  NE-DIAGONAL  FROM 

REMAINING-NE-DIAGONALS) 

(REMOVE*  SE-DIAGONAL  FROM 

REMAINING-SE-DIAGONALS) ) 

(DETERMINE*  BOARD-POSITION  FROM 

(CORRESPONDING-BOARD-POSmON  BOARD-POSITION 

ROW  COLUMN)) 

(ASSERT  (PIECE-ON-BOARD  Ql^EN  BOARD-POSITION)) 

(IF  (SUCCESSFUL  (RECURSIVE-CALL:  (QUEENS  QUEEN -SET 

REMAINING-ROWS 

REMAINING-COLUMNS 

REMAINING-NE-DIAGONALS 

REMAINING-SE-DIAGONALS) 

THEN  (LOOP-RETURN  CHOICE-ACCEPTED) 

ELSE  (UNDO-ACTIONS:  (DENY  (PIECE-ON-BOARD  QUEEN 

BOARD-POSITION)) 

(MAINTENANCE-ACTIONS:  (ADD  ROW  TO 
REMAINING-ROWS) 

(ADD  COLUMN  TO 
REMAINING-COLUMNS) 

(ADD  NE-DIAGONAL  TO 
REMAINING-NE-DIAGONALS) 

(ADD  SE-DIAGONAL  TO 
REMAINING-SE-DIAGONALS) 

(LOOP-RETURN  FORCE-ANOTHER-CHQICEi  i 
THEN  (EXIT  SUCCESSFUL) 

ELSE  (UNOO-ACTCNS:  (ADO  QUEEN  TO  QUEEN-SET) ) 

(EXIT  UNSUCCESSFUU 
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